EDITIONDATE (поле)
Материал из GedeminWiki
(Различия между версиями)
SYSDBA (обсуждение | вклад) |
SYSDBA (обсуждение | вклад) |
||
| Строка 7: | Строка 7: | ||
обновления этого поля по следующим причинам: | обновления этого поля по следующим причинам: | ||
| − | # '''Производительность.''' Например, в [http://code.google.com/p/gedemin/issues/detail?id=1053 случае изменения editiondate в таблице at_relations] в ответ на изменение записи в at_relation_fields, в процессе синхронизации | + | # '''Производительность.''' Например, в [http://code.google.com/p/gedemin/issues/detail?id=1053 случае изменения editiondate в таблице at_relations] в ответ на изменение записи в at_relation_fields, в процессе синхронизации метаданных для таблицы с N полей N раз вызовется триггер на обновление мастер записи. |
| − | метаданных для таблицы с N полей N раз вызовется триггер на обновление мастер записи. | + | # '''Вероятность возникновения ошибки.''' Если принцип обновления editiondate применять повсеместно, то начнутся каскадные апдейты и даже может возникнуть рекурсия. |
| − | # '''Вероятность возникновения ошибки.''' Если принцип обновления editiondate применять | + | # '''Логическая размытость (неясность) в каком случае обновлять, а в каком нет.''' Например, если обновлять таблицу при изменении записи в таблице с полями, то почему тогда не обновлять запись в таблице с полями (а за ней и запись в таблице с позициями) при изменении записи в таблице с доменами? Пример не из метаданных: стоит ли менять editiondate у документа накладной, если изменился адрес контрагента? Вроде бы нет -- контрагент эта запись в таблице справочнике, связанная с накладной. Но, с другой стороны, для пользователя накладная -- это то что отпечаталось на листе бумаги, и для него изменение адреса в накладной -- это и есть изменение накладной. Значит, да? |
| − | повсеместно, то начнутся каскадные апдейты и даже может возникнуть рекурсия. | + | |
| − | # '''Логическая размытость (неясность) в каком случае обновлять, а в каком нет.''' Например, если обновлять таблицу при изменении записи в таблице с полями, то почему | + | |
| − | тогда не обновлять запись в таблице с полями (а за ней и запись в таблице с позициями) при изменении записи в таблице с доменами? | + | |
| − | + | [[Category:База данных]] | |
| − | + | ||
| − | + | ||
Текущая версия на 16:13, 28 августа 2008
Строго говоря, Гедымин требует обновления поля editiondate только в двух случаях:
- меняются данные непосредственно в самой таблице, где находится это поле;
- меняются данные в таблице связанной 1-к-1 (например, gd_contact - gd_company).
В остальных случаях решение принимается разработчиком. Мы не требуем жесткого обновления этого поля по следующим причинам:
- Производительность. Например, в случае изменения editiondate в таблице at_relations в ответ на изменение записи в at_relation_fields, в процессе синхронизации метаданных для таблицы с N полей N раз вызовется триггер на обновление мастер записи.
- Вероятность возникновения ошибки. Если принцип обновления editiondate применять повсеместно, то начнутся каскадные апдейты и даже может возникнуть рекурсия.
- Логическая размытость (неясность) в каком случае обновлять, а в каком нет. Например, если обновлять таблицу при изменении записи в таблице с полями, то почему тогда не обновлять запись в таблице с полями (а за ней и запись в таблице с позициями) при изменении записи в таблице с доменами? Пример не из метаданных: стоит ли менять editiondate у документа накладной, если изменился адрес контрагента? Вроде бы нет -- контрагент эта запись в таблице справочнике, связанная с накладной. Но, с другой стороны, для пользователя накладная -- это то что отпечаталось на листе бумаги, и для него изменение адреса в накладной -- это и есть изменение накладной. Значит, да?
