|
|
|
История замещений
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Предметная область -- организация семинаров и тренингов В силу особенностей предметной области штатной является ситуация всевозможных "переносов". Так, например, тренинг был запланирован на определённую дату. Начали его рекламировать. Группа не набралась, поэтому тренинг перенесли на другую дату. Следовательно, необходимо - связаться с теми, кто прислал заявку, выяснив, согласны ли они подождать следующего такого же тренинга или прийти на сходный по тематике из числа тех, которые точно будут проводиться: -перезаключить договор с теми, кто согласился подождать -перезачесть оплату если они уже успели оплатить счёт -выставить счёт на недостающую сумму\вернуть часть денег, если семинар сходной тематики отличается ценой от предыдущего и.т.д.... В итоге: Необходимо спроектировать БД так, чтобы была возможность а)регистрации истории изменений свойств объекта например --"тренинг"(время, место проаедения,продолжительность, программа и.т.д.) б)автоматического изменения любых свойств всех зависимых объектов например -- "заявка"(количество участников,номерсчета,суммаоплаты и.т.д.) Отсутствие чётких правил (.....)не позволяет заранее однозначно определить все необходимые зависимости Единственное, что пришло в голову мне -- это связывать таблицу, содержащую информацию об объекте саму с собой M:M и при каждом изменении некоторого свойства, запускать транзакцю: -Изменяем статус актуальности текущего объекта(неактуален) -добавляем новую запись в связующую таблицу изменений(IDСтарогоОбъекта-uniqe,IDНовогоОбъекта,ТипИзменения,ДатаРегистрацииИзменения) -Изменяем статус актуальности нового объекта (теперь актуален) В итоге новый актуальный объект наследует все актуальные свойства старого, сохраняя историю своих неактуальных состояний. Но если учесть, что таких объектов в перспективе довольно много (ну скажем до полсотни -- больше я в таком бардаке не переживу) и глубину рекурсии заранее не ограничить, а значит всякое случайное изменение надо будет замещать ещё одной записью, не говоря уже про изолированность транзакций и.т.д. -- мне мягко говоря всё это не кажется оптимальным. Подскажите пожалуйста, как подобные задачи решают по-людски? Если факты противоречат моей теории, тем хуже для фактов © ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2008, 03:21 |
|
||
|
История замещений
|
|||
|---|---|---|---|
|
#18+
1) А как вяжется исходная задача с теми предложениями, которые Вы предлагаете (с версионностью)? 2) Если Вам интересно про версионность - попробуйте нажать кнопачку "Поиск" - она там вверху справа, предпоследняя. Очень много последнее время обсуждалось про версионность объектов/документов/параметров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2008, 11:25 |
|
||
|
История замещений
|
|||
|---|---|---|---|
|
#18+
> Подскажите пожалуйста, как подобные задачи решают по-людски? Осознайте, что никаких объектов в реляционной базе данных нет. В принципе. Для того, чтобы они появились, вам понадобится метамодель вашей базы данных. На основе метамодели, которая должна поддерживать и стереотипы РСУБД, и стереотипы нужной вам модели, строятся связи между сущностями, которые, в свою очередь, используются для изменения их состояний. Примерно так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2008, 12:33 |
|
||
|
История замещений
|
|||
|---|---|---|---|
|
#18+
Есть плановые показатели, есть фактические. Ещё несостоявшееся занятие, это план. Как только на него начали записываться люди, заключать договора, вносить предоплату, это уже фактические данные. Фактические и плановые данные не имеют жётской связи, типа ограничений ссылочной целостности и т.п.. Т.е. удаление записи из плана не должно приводить к изменению счетов и договоров (все эти изменения будут выполняться вручную по ходу перезаключения договоров и перерасчёта стоимости). Чтобы отслеживать изменения в занятиях нужно объединить все документы связанные с этим занятием в дело, с которым связывать все планы и факты. Дело открывается под определённое занятие, запланированное на определённое время. Если план изменился, нужно открыть новое дело и перенести в него (или в другие дела, связанные с другими занятиями) заявки, договора, счета и т.п., по мере согласования нового плана с клиентами. Дело закрывается (уходит в архив), когда занятие состоялось или когда занятие было отменено и все связанные с делом документы были перемещены в другие дела (на другие занятия в другое время и т.п.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2008, 14:05 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=95&tid=1543542]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
78ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 392ms |

| 0 / 0 |
