2015-05-25 5 views
0

Я разрабатываю таблицу изменений, в которой я в основном записываю старое и новое значение для изменений в полях двух типов: десятичное и datetime.SQL Server - сохранение даты и времени

Чтобы сделать это простым, я думал о создании строкового поля и преобразовании значений в строку перед хранением в таблице. Моя проблема в том, что позже мне нужно будет создать поле в отчете, чтобы показать разницу между изменениями (например, если дата изменилась с 01/20/2015 по 01/27/2015, разница будет равна 7 и так далее на). Я не хочу создавать поле в таблице для записи разницы между полями, я хочу сделать это в стороне отчета.

Мой вопрос: Есть ли способ сохранить эти два вида данных (десятичные и datetime), чтобы упростить сравнение позже? Причина, если у меня это в строковом типе, мне придется преобразовать его два раза - один, прежде чем создавать запись в БД, а другой - посмотреть, в чем разница между ними.

+0

Вы можете легко «CAST (stringfield AS DATE)» на конце, но я не понимаю, почему вы не хотите использовать поле «DATE». –

+0

А почему бы не хранить в истории реальные типы этих столбцов? –

+0

Если вы сохраняете даты, используйте соответствующий тип данных, это 'DATE' или' DATETIME', это позволит вам использовать встроенные функции DATETIME и сделает вашу жизнь проще. Вы сделали хороший выбор: не хранить разницу между значениями, это то, что вы должны делать во время выполнения. –

ответ

0

Я считаю, что наилучшим подходом было бы то, что я хотел бы назвать никогда не удалять, никогда не применять подход.
В принципе, вы добавляете столбец в свою исходную таблицу для статуса записи, которая может быть либо current, historic, либо deleted (используйте для этого только миниатюру, просто убедитесь, что она привязана к таблице состояния строк для удобства чтения). то вместо того, чтобы удалять запись, которую вы обновляете, ее статус удаляется, и вместо ее обновления вы меняете статус на исторический, а затем вставляете новую запись с новыми данными.

Естественно, этот подход имеет свою цену, так как вам придется писать вместо триггера обновления, но это небольшая цена для оплаты по сравнению с другими подходами хранения исторических данных.
Кроме того, если ваш первичный ключ не является столбцом identity, вам нужно будет добавить этот столбец в свой первичный ключ (и любые другие уникальные ограничения, которые могут возникнуть у вас).
Вы также можете добавить фильтр в свои некластеризованные индексы, чтобы они индексировали записи, в которых текущий статус.

+0

Привет, Зоар, мне понравилась ваша идея. В этом случае у меня будет изменить поведение программы (изменить логику для создания новой записи, а не обновлять текущую), или вы думаете, что я могу сделать это только в размере БД (создать триггер для создания новой записи при обновлении и отменить обновление сам). Каков наилучший способ сделать это? –

+0

Безопасным способом является создание триггера 'вместо обновления '. Таким образом, вы гарантируете, что даже если записи были обработаны непосредственно из SSMS, они все равно не будут обновлены (кроме столбца состояния), и будет вставлена ​​новая запись. –

+0

Моему боссу не понравилась идея столбца идентификации из-за необходимых изменений в стороне ERP - показать только текущие записи. Тем не менее, вы заставляете меня думать о боли, которую я получаю по своей идее, поэтому я голосую за ваш ответ как правильный. Спасибо (: Пс .: Я просто создаю зеркальную таблицу с обоими полями. –

Смежные вопросы