проектирование БД

[iceman]

проектирование БД

сразу к примеру:

Есть таблица заказов TB_ORDER,
Есть таблица договоров TB_CONTRACT,
Есть таблица цен для каждого договора TB_CONTRACT_PRICE

...

теперь сама программа:

Создаю заказ, сумму заказа считаю взяв поле из TB_CONTRACT_PRICE ну и, например, кол-во штук чего либо. Сохраняю.


Но возможен такой случай, когда заявка сохранена, ее нужно отредактировать, но при этом в таблице TB_CONTRACT_PRICE поменялось значение цены. При редактирование в итоге изменится сумма, хотя нужна старая.

что делать? мне предлагают хранить в таблице TB_ORDER поле с ценой. НО:

этот случай не конкретный, таких случаев вообще много стало появятся в моей работе. т.е. информация в справочнике может изменится, но в заявке либо еще где-нибудь должна остаться старая информация. НУ НЕ ДО БЕСКОНЕЧНОСТИ же добавлять дублирующие поля, и мне кажется это вообще НЕ ПРАВИЛЬНО!

как вы решаете данную проблему?

 

[craz]

такое ощущение что нужна еще одна таблица... и трогать не придется существующие
возможно этой таблицей будет таблица с заказом

 

[iceman]

я добавил дублирующие поля в таблицу заказов, она выросла в 3 раза, меня это напрягает...

 

[craz]

надо новую таблу с текущими заказами и чистить ее если заказ выполнен

 

[Fortop]

Но возможен такой случай, когда заявка сохранена, ее нужно отредактировать, но при этом в таблице TB_CONTRACT_PRICE поменялось значение цены. При редактирование в итоге изменится сумма, хотя нужна старая.

Дублировать поля нет смысла. Ты ломаешь себе весь OLAP

Во избежание проблем.
Новые цены уже принятой заявки = новая заявка.

Редактирование допустимо только на этапе draft к примеру.
Далее. Цены TB_CONTRACT_PRICE, я очень сильно надеюсь, что в них лежат не текущие цены, а вообще все цены на любую дату.

Если же я ошибаюсь, то это надо исправлять и хранить отдельно цены на каждый конкретный период времени.

 

[iceman]

ну по ценам это тоже надумал...

а еще например, был случай, уже документооборот, во исходящем письме нужно было дублировать поля автора, его адрес, телефон индекс и т.д. так как информация об авторе может изменится в справочнике, но письмо должно иметь данные старые на момент регистрации входящего письма...

там тоже чтоли дату поставить? и организовать иерархию авторов (тут корень использовать для регистрации новых входящих, а дочерние для исходящих)?

 

[Fortop]

Не надо иерархии.
ID автора меняться не может.
Он единственный на все время жизни системы. В ERP, CRM, документообороте - ничего никогда не удаляется.

У документов, контрактов, пользователей могут меняться статусы, они могут увольняться и т.д., но их данные остаются в системе.

В простейших случаях, если не нужен полный и всеобъемлющий учет - производится денормализация. И в поле автор письма заносится конкретная информация, а не ID при это редактировать эту информацию уже нельзя. Т.е. то о чем я говорил выше, если вдруг новые цены - это новая заявка/договор с новым ID. Пусть даже для конечного пользователя это и выглядит как редактирование старого документа.

-~{}~ 29.04.10 09:26:

Как вариант версионирование документов. Т.е. уникальным ключем является не ID документа, а ID + create_date

-~{}~ 29.04.10 09:30:

Мгм, уточнение по связанной информации. Данные которые связаны с другими сущностями - не меняются.
Если у автора вдруг поменяется ФИО (такое бывает), то появляется или новый автор, или система должна допускать наличие у автора нескольких ФИО.