Привет всем!
Наконец-то появилась достаточно абстрактная (а то учет уже надоел, мне по-крайней мере), интересная и полезная тема, применимая ко многим областям :)
2 manumba:
Нужно организовать ведение истории для некоторых данных...Например, есть таблица в полями ФАМИЛИЯ, ИМЯ. Потом человек меняет фамилию и это должно быть учтено в БД....и это нужно сделать для многих других данных (для многих таблиц). В последствии работа ведется как обычно с новыми данными, но должна быть возможность получить старые данные.....
Как это обычно делают? Как нужно для этого организовывать таблицы?
Да - отдельные таблицы под
старые и под
новые данные . По-крайней мере такое у меня было в опыте пару раз так и делали, модель удовлетворила всех и прекрасно работает до сих пор. Так что полностью согласен Циничным Котом, но только IMHO 2-й путь НЕ лучше - он
единственно возможный , т.е уникальный ИД на всю жизнь, а каскадные изменения - это только способ обеспечения пользовательской целостности в масшатабах всей системы - тоже отдельная подтема.
В 1-м варианте можно хранить исторические данные и кто их записал. Во 2-м варианте - также и что(какие атрибуты), но это уже посложнее.
Если 1-й вариант вариант, то как это можно реализовать в общих чертах:
Сущность
Текущие Данные - это текущие, самые последние данные о лице:
1.
2.
3.
ИД_Лица = <уникальный ИД лица (вечный)> (PK)
ИД_Пользователя = <ИД пользователя, к-рый сделал запись данных> (FK)
ДатаЗаписи = <дата-время записи данных (их актуальность)>
...остальные описательные атрибуты лица...
Сущность
Исторические Данные - это все исторические данные о лице, т.е все измения фактов или записей в таблице
Текущие Данные :
1.
2.
3.
4.
ИД_Записи = <уникальный ИД изменения> (PK)
ИД_Лица = <уникальный ИД лица> (FK)
ИД_Пользователя = <ИД пользователя, к-рый сделал запись данных> (FK)
ДатаЗаписи = <дата-время записи данных>
...описательные атрибуты лица, к-рые могут изменять значения...
Примечания:
* Вместо
суррогатного ключа ИД_Записи в
Исторические Данные можно также использовать натуральный композитный ключ например (ИД_Лица, ДатаИзмения,...)
* Вместо ИД_Пользователя, меняющего записи может быть ИД_Сотрудника
Т.е логика такова - при очередном изменении строка из
Текущие Данные с помощью триггера переносится в таблицу
Исторические Данные , при этом триггер сначала проверяет, что хотя бы один столбец изменил значение
