Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
История
|
|||
|---|---|---|---|
|
#18+
Есть такая задача документооборота: имеется документ (договор). К нему привязаны другие объекты, являющеся его содержимым. К договору имеются дополнительные соглашения, которые изменили как состояние самого договора, так и его содержимого. Необходимо сохранять все состояния договора (доп. соглашений) и их содержимого. Есть два решения: 1. Сделать шапку и тело договора. К телу крепить содержимое. При каждом изменении договора делать новую запись в тело и копировать содержимое к этой новой записи. 2. Делать для договора и каждой таблицы содержимого доп. таблицу с записями типа дата | значения. Готов рассмотреть все возможные варианты, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2005, 16:51 |
|
||
|
История
|
|||
|---|---|---|---|
|
#18+
Я бы пошел по первому пути, только не забудте в таблице-шапке сделать ссылку на последную правильную запись в таблице истории. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2005, 09:44 |
|
||
|
История
|
|||
|---|---|---|---|
|
#18+
Я делаю полную дублирующую структуру, т.е. если есть таблицы "шапка", "содержимое", делаются таблицы истории: шапка_история, содержимое_история с аналогичной структурой. В таблицы истории записи попадают не только при изменени, но и при создании. В основной таблице - всегда актуальная запись. В таблице истории - дата версии записи, ссылка на запись основной таблицы. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2005, 12:12 |
|
||
|
История
|
|||
|---|---|---|---|
|
#18+
Решил постить в эту тему, если вы не против Есть две сущности, А и Б, связаны отношением один ко многим. Сущности Б могут на протяжении времени меняться (висят на истории) - но при добавлении связим между А и Б при просмотре А должны выводиться только те Б, которые были именно для нее добавлены. как можно красиво это реализовать: Сущность Б имеет два UID: 1-й для идентификации в системе и 2-й отображает номер версии и когда Б связывается с А, то связь происходит по этим двум uid? Вы предпочитаете реализовывать историю на тригерах? Или каким то другим механизмом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2005, 13:12 |
|
||
|
История
|
|||
|---|---|---|---|
|
#18+
ID версии А можно сделать уникальным по таблице версий ВА. Т.е. миграция ключа неидентифицирующая: ВА.А_ID останется ссылкой на А но не войдет в первичный ключ ВА. Версия Б будет ссылаться на версию А по единственному полю. Плюсы - единообразие. Минусы - больше джойнов. В каждом конкретном случае выбор разный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2005, 15:43 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33168019&tid=1545752]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 268ms |
| total: | 394ms |

| 0 / 0 |
