Если начать с концептуальной модели, то ответ звучит просто: наследование. Т.е. создается entity Prices, содержащий поле dPrice, от которого наследуются нужные таблицы.
Разумеется, нужно построить физическую модель. Если мы строим ее по схеме "генерация родителя и потомков с наследованием ключа", то получается тот способ, который ты описал как "заменить dPrice на iPriceID".
При другом варианте генерации PK потомков перетекают в родителя. В этом случае никакого iPriceID не будет, а в таблицк цен будет композиция всех ключевых полей из твоих таблиц.
Что же до дурдома, то на него вполне похож третий -- на самом деле тоже логичный -- вариант: ВСЕ генерится в одну таблицу с композицией всех собственных полей наследников с полем dPricе, доставшимся от папы.
Обращаю внимание: все три схемы логически эквивалентны и в каждой из них dPrice лежит ровно в одной таблице.
Цитата:
|
Думаю сделать следующее - в orders - добавить поле dPrice и каждый раз при добавлении новой услуги - пересчитывать поле общей стоимости.
|
Не забудь про блокировки. Этот способ хорош в плане минимизации правок, но потенциально может создать больше всего проблем.