Long Live Torrent Trackers !Inkelyad,

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

Например, встал методолог не с той ноги (или у методологички сложные дни) - програмер покивал головой (мол, усё сделаем), залез в хранимую процедурку (ALTER PROCEDURE ...) и глядь - через полдня усё действительно готово - процедурка выдаёт другой результат в соответствии с изменившимися правилами.

а кто constraints будет ослеживать? как на клиенте логику менять?

Long Live Torrent Trackers !guest_20040621> На первом этапе может тара вобще не рассматривалась как критерий и не учитывалась.

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

Увы,
уважаемый mikron никак не может успокоиться и взять себя в руки (молодая горячая кровь).
Он все порывается по каждому чиху изменять схему БД.
Тара не рассматривалась как критерий, а теперь рассматривается - выход один - срочно менять схему БД !
Изменился цвет бутылок с зелёного на коричневый - спасёт только изменение схемы БД.
Бутылки были литровые, а стали двухлитровые - менять, менять схему БД !

Подозреваю, что на работе он так всё же не делает.

уподдерживаю предыдущих товарищей - вы товарисч - Троль - если у вас меняется схема данных а вы ее не меняете в БД, а все держите в коде - подпускать вас к проектированию БД опасно - у вас нет представления зачем нужны БД

Ivan Durakконечно.. eav для ВСЕГО - решит все проблемы :)

+1, и Эксель его лучший брат!)))

ChopspПоделитесь пожалуйста опытом борьбы с таким явлением. Есть ли какие либо способы или шаблоны проектирования такого безобразия!? )1. когда Заказчик грит "у меня в таблице Контрагентов будет только три номера телефона, зуб даю" -
я автоматом создаю подчиненную таблицу "один-ко-многим", а не добавляю три поля в таблицу контрагентов

тут все понятно и банально..

Chop2. для расчета тарифов реализовал N-мерную матрицу в БД,
после этого - что цифирки меняйте, что количество параметров...

т.е. если у меня 24 параметра и многие из них списочные с иерархическими зависимостями от других параметров - вы предлагаете строить (затрудняюсь как называется такое...) 24х24Х...... куб или как его там получится????

Chopкак-то так...

грят, еще можно доки сохранять одним xml-полем...
без изменения структуры БД доки можно ваять хоть по одному новому каждый час :)
никогда не видел, только слышал :)

В этом варианте вам и БД не нужна - держите все в коде! - БД нужна для хранения непротиворичивых и целостных данных, а в случае с xml - это просто текст а не БД!

Chopне вижу проблемы...

1. многомерная матрица/куб в БД (в моей реализации это было дерево+ЕАВ)
2. создание нового тарификатора на основании предыдущего (для упрощения ввода новых цифирь и параметров)
3. "запоминание" периода действия "тарификатора"

фсе... документы никакие не меняются, структура БД не меняется

я вам таки ее добалю...)
параметры - не просто одинокие цыхверки - а справочники с иерархическими зависимостями между другими справочниками-списками
Интересно как вы ничего не будете менять если меняются связи и условия в этих иерархических зависимостях?

Cane Cat FisherЯ тоже не вижу проблем, если спокойно применить эволюционный подход. Сделайте для каждого варианта нормальную реляционную схему. Если постановка расширяется, меняется - сделайте новые поля, или новые таблицы. Организуйте код, чтобы "диспетчеризация" старых-новых полей-таблиц сидела строго в одном месте сервисного слоя системы. Работайте только через этот слой.

Преимущества: каждый отдельный кусок БД остается простым, понятным, реляционным - со справочниками, связями, декларативным контролем целостности и т.д. Не боится расширения в любую сторону.

Все это, как и мнения предыдущих ораторов, доказывает: нет ничего сложного в работе, которую не обязан делать сам :-)

Спасибо за конструктивный и рациональный ответ!

Chopпараметр он параметр и есть,
подозреваю, что под "параметр - справочник" вы подразумеваете,
что каждый элемент справочника используется как параметр
ничего от этого не меняется,
вместо текстового/цифрового значения будет стоять ссылка,
только и всего

Нет - вы неправильно подозреваете: параметр-список это список, значение которого выбирается в зависимости от текущих значений нескольких связанных параметров-списков. К примеру: если сегодня день недели (список дней недели) - пятница и руководит цехом Иванов (список руководителей цеха) и сегодня 3я фаза лунного цикла (список фаз) то в суп добавить 1.5767 мг соли. При других значениях зависимостей - другое значение соли - список. Да, еще и при этом каждое значение в списках "день недели", "руководители цеха", "фазы луны" имеют свои весовые коэффициенты, которые участвуют в расчете других параметров.!
Как вам такая каша!?) думаете выдумываю - нет! утрирую -да!)