Расскажу о реальной эволюции крохотной части БД, с которой пришлось столкнуться.

Итак, биллинговая система - расчеты с населением за газ. Вопрос цены.

1. Давным-давно, когда система начинала проектироваться, цена была выбита на огромном камне для всего СССР, и не было величины постояннее. Поэтому сначала это была константа в коде.

2. Затем цена стала расти со временем. Появилась таблица PRICES(DATE_ACCEPT, DATE_FROM, PRICE) (две даты - для учета изменений задним числом: в каком отчетном периоде учитывается, с какой расчетной даты пересчитывается).

Константа в коде заменилась на функцию get_price(ADATE_ACCEPT, ADATE_FROM), внутри нее сидело обращение к таблице.

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

Программисты поматерились, и ответили на это тремя важными шагами:

а) у функции get_price добавили параметр ABONENT_ID. Теперь функция внутри себя лезла в параметры абонента и смотрела, есть ли у него счетчик.

б) в зависимости от этого, она по-разному обращалась к таблице PRICES. Туда вроде бы добавили поле PRICE_BY_METER с ценой для счетчиков. Или ввели логический признак WITH_METER и помножили строки. Или вообще сделали новую таблицу. Я специально напускаю в этом месте туману, поскольку уже не помню подробностей, и это правильно. Потому что:

в) ...подробности отныне и навеки остались внутри функции get_price. Все прямые SQL-обращения к таблицам PRICE и им подобным были запрещены.

4. Затем цены стали зависеть от многоквартирности дома. Добавили таблицу (или поля, не помню).
5. Затем это отменили, и ввели особые цены для отопления, и для его отсутствия. Добавили таблицу (-..-).
6. Затем вспомнили про автономное отопление в многоквартирных домах, и ввели для него особые цены. Добавили таблицу (-..-).
7. Затем ввели целых десять цен, в зависимости от годового объема потребления газа. Добавили таблицу (-..-).
8. Надо ли говорить, что все эти категории цен продолжали расти со временем. Записи множились.

...А весь остальной код на все это не обращал внимания. Вызывал себе функцию get_price, и все. Ее формат вызова не менялся: get_price(ADATE_ACCEPT, ADATE_FROM, ABONENT_ID).

Внутри get_price был большой некрасивый CASE, и, в зависимости от заданного периода и данных абонента, шли обращения к нужным полям нужных таблиц. Но об этом знала только get_price.

Мораль: нужно предвидеть, где будут частые изменения в будущем, и максимально программно изолировать этот кусок от остального кода. Как учил товарищ Гради Буч, сложность системы определяется не количеством объектов, а количеством и характером связей между ними. Упрощайте логические связи, не допускайте лишних обращений одних подсистем в потроха к другим. И тогда отдельные подсистемы можно будет переделывать быстро и легко, без ущерба для остальных.

Замечание по производительности. Результаты расчетов хранятся в отдельной таблице - расчетной ведомости, которая слегка денормализована: в нее подтянуты фактические значения цен и других параметров, использовавшихся при расчете. Поэтому при формировании отчетов не нужно снова многократно вызывать функцию get_price, которая, конечно, получилась слегка громоздкой, а берутся сохраненные значения.

spесли изделие из такого-то цеха и поставляется в такой регион - коэффициент 1 для параметра #1.
Если параметр #1 имеет значение 1 и покупатель не плательщик НДС и из Лондона - то параметр №2 = 0.5

Не шучу! все так и представлено - важно в этом процессе - конечная стоимость, а она формируется такими вот правилами и значениями!
В следующей версии Лондона может и не быть вообще и второе правило переписано так: если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2!!!

Ничего особенного в этом я не вижу. Только я бы не стал моделировать все это структурами БД, а реализовал в каком-то месте прикладного кода. Со всей историей правил, диапазонами действия во времени и т.д. Особый вопрос - проверка полноты правил, то есть охвата всех возможных комбинаций параметров. "Если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2". А если не Пупкин, или Пупкин но не кожа в Цехе № 2, то что?