Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, уважаемые! Возникла тут задача написания небольшой кадровой системы. В связи с этим захотелось иметь механизм отслеживания изменений данных. К примеру есть сущность Персона с аттрибутом Фамилия. До 1.01.2001 была фамлия Петров, а потом стала Иванов. Соответсвенно в документах, которые ссылаются на Персону, датированных до 1.01.2001 должна появляться Петров, а после Иванов. Этот механизм по идее должен распространятся и на другие атрибуты и другие сущности. Т.е. измениться может и адрес и паспорт и занимемая должность. Но что-то я не могу подобрать нормальную структуру для реализации подобного механизма. В голову приходит что-то уж совсем абстрактное, типа: table OBJECTS(ObjId int, ObjClass id, ParentObjId int) table ATTRIBUTES( ObjId int, ATTRIBId int, FROM_Date datetime, TO_DATE datetime, Val_type int, Val_Int int, Val_char varchar, Val_Date datetime, Val_Money money) Это конечно сильно утрировано, но смысл должен быть понятен. Я никогда с подобными схемами не работал - по-моему это не вполне реляционный подход и с его реализацией могут возникнуть проблемы. По-этому хочется спросить у уважаемых мной посетителей форума - если кто реализовывал подобные схемы, какие тут есть подводные камни (в частности возможность построения эффективных запросов с условиями по нескольким атрибутам), стоит ли вообще за это браться, или другие предложения по реализации механизма отслеживания изменений данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2001, 08:46 |
|
||
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
Такие вещи очень просто отследить с помощью таблиц в которых храниться история изменений. Как это сделать - просто прикинуть что и как нужно хранить и вперед, можно создать триггер, который при изменении определенных колонок отправляет инормацию в таблицу-историю с предидущими данными, а те что изменились остаются в основной таблице. И так далее, изменилось опять опять занесли...Велосипед изобретать не надо, все уже придумано... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2001, 16:22 |
|
||
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
В SQL2000 есть тип данных sql_variant, который позволяет сохранять и читать данные любых(почти) типов соответственно. Поэтому таблица ATTRIBUTES может выглядеть так ObjId int, ATTRIBId int, FROM_Date datetime, TO_DATE datetime, Val_type int, Val_value sql_variant есть одно ограничение - если фактическая длина заносимых в запись данных превысит 8060 байт произойдет ошибка. Но при предложенной структуре у вас остается 8060 - 4 - 4 - 8 - 8 - 4 = 8032 байта ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2001, 19:16 |
|
||
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
Меня тоже интересует этот вопрос. Идея хранения в доп таблице с помощью триггеров мне приходила, но вот еще вопрос- ведь все изменения записываются в лог файл. Можно ли его как нибудь читать(хотябы как текст)? Я нигде не смог найти об этом информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2001, 06:24 |
|
||
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
Владимир правильно сказал у меня это реализованно так table Person (idrow(pk),idperson(fk),fam,name,secname,....,begindate,enddate) где begindate,enddate -период когла данные были правильные для актуальной информации enddate >> текущей даты (у меня 31/12/2099) для 2000 реализованн udf который возвращает эту дату изображаешь тригера и медод получения данных для старых данных, Да в этом случае индефикатор человека не может быть PK, надо создавать некую таблицу в которой будут храниться эти уникальные значения (как правило получается таблица с одним полем которая служит самым верхнрм pk) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2001, 06:34 |
|
||
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
2Daymon А если несколько пользователей одновременно(или поочередно) в течении короткого промежутка(скажем 10-15 мин) времени правят(каждый по своему) значение одного и того же аттрибута, то как вы в том случае определяете потом актуальное значение этого аттрибута - ведь за этот же промежуток времени могло быть создано несколько документов, ссылающихся на сущность Персона (если пользоваться примером Михаила Куркова) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2001, 07:02 |
|
||
|
Отслеживание изменений данных
|
|||
|---|---|---|---|
|
#18+
To Glory, Daymon Владимир собственно совсем о другом говорил: Таблица с персонами - это одна таблица, там лежат только актуальные данные и все, чего мудрить то. Таблица с историей изменений - это другая таблица, там лежат старые данные и дата, до которой они были действительны, типа: EndDate, Name, FName, MName ... и т.д. Ни каких нескольких документов ни на кого не ссылается. Хоть сотня человек изменит данные за 5 минут в таблицу изменений будут ложиться те данные, которые были на момент изменения в таблице. Стандартный же прием, об этом Владимир и говорил, чего выдумывать. А со структурой Daymon возможна конечно некоторая путаница. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2001, 05:40 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32014945&tid=1825369]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
24ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 362ms |

| 0 / 0 |
