поддержите историю в базе данных
Ваш общий анализ верен, я получил то, что вы хотели бы достичь, но встроенные красивые форматы, к сожалению, исправлены .
Из документа :
Обратите внимание, что псевдоним с таким же именем, как у встроенного формата, будет игнорироваться.
blockquote>Тем не менее, разница между этими двумя git-средами может быть нивелирована другим способом. Может быть, стоит рассмотреть возможность установки обеих установок на одну и ту же версию git?
5 ответов
Посмотрите http: //www.simple-talk. com / sql / database-Administration / Database-Design-a-Point-in-Time-Architecture .
В основном, статья предполагает, что у вас есть следующие столбцы в таблицах, для которых нужно отслеживать историю - -
* DateCreated – the actual date on which the given row was inserted.
* DateEffective – the date on which the given row became effective.
* DateEnd – the date on which the given row ceased to be effective.
* DateReplaced – the date on which the given row was replaced by another row.
* OperatorCode – the unique identifier of the person (or system) that created the row.
DateEffective и DateEnd вместе сообщают вам время, в течение которого строка была действительной (или время, в течение которого сотрудник находился в отделе, или время, за которое он заработал определенную зарплату).
Хорошая идея - хранить эту логику внутри базы данных: именно поэтому существуют триггеры. Я говорю это осторожно, однако, поскольку есть много причин, чтобы держать это внешним. Часто - особенно с такой простой технологией, как LINQ-to-SQL - легче писать код извне. По моему опыту, больше людей могли бы написать эту логику в C # / LINQ, чем могли бы сделать это правильно, используя триггер.
Триггеры быстрые - они скомпилированы! Тем не менее, ими очень легко злоупотреблять, и они делают вашу логику слишком сложной, чтобы производительность могла быстро ухудшаться. Учитывая, насколько прост ваш вариант использования, я бы предпочел использовать триггеры , но это лично для меня.
Триггеры, скорее всего, будут быстрее, и для их выполнения не потребуется «посредник», устраняя при как минимум один шанс на ошибку.
В зависимости от выбранной вами базы данных, вы можете просто использовать одну таблицу и включить для нее OID, а также добавить еще два столбца, «flag» и «previous». Никогда не обновляйте эту таблицу, только вставьте. Добавьте триггер так, чтобы при добавлении строки для employee #id, для всех записей с employee #id был установлен флаг «old», а для новых строк «предыдущие» значения устанавливались в предыдущую строку.
Я думаю, что это входит в базу данных по двум причинам.
Во-первых, промежуточные уровни приходят и уходят, но базы данных вечны. В этом году Java EJBs, в следующем году .NET, через год что-то еще. По моему опыту, данные остаются.
Во-вторых, если база данных является общей, ей не нужно полагаться на каждое приложение, которое использует ее, чтобы знать, как поддерживать целостность данных. Я бы посчитал это примером инкапсуляции базы данных. Зачем навязывать знания и вести историю каждому клиенту?
Триггеры облегчают переход вашего интерфейса на что-то другое, и они будут поддерживать согласованность базы данных независимо от того, как данные вставляются / обновляются / удаляются.
Кроме того, в вашем случае я бы записал зарплаты прямо в историю зарплат - из вашего описания я не вижу причины, по которой вы должны пройти путь через триггер обновления на таблица сотрудников.