Dogen CalmНормализация БД никак не припятствует мультиплатформенности.
Впрочем в нормализации тоже следует быть умеренным.
А это типичный подход технарей, мало занимавшихся эксплуатацией - надо шоб было все нормализовано и т.д. и т.п. А потом запросы писать к восемнадцати таблицам вместо трех.
Мне кажется, Вы не сталкивались с проблемами, возникшими из-за "нетехнарского" подхода. Или Вы - "внедренец"...
"Технарь" не станет жертвовать нормализацией ради уменьшения кол-ва таблиц в запросе. А вот "внедренец", которому это облегчит процесс "впаривания" - запросто.
Бизнесу всё равно, сколько таблиц в запросе.

Dogen John 3VoltaБизнесу всё равно, сколько таблиц в запросе.Верно, бизнесу все равно. Бизнесу не все равно конечный результат.Здесь возникает дилема: или правильная структура базы, но система не соответствует требованиям заказчика, или "неправильная" база с вытекающими последствиями. Единственный правильный с моей точки зрения вариант - третий :), а именно: доработка под требования без "денормализации" (то есть практически не реально).

DogenХотелось бы также послушать про примеры гениальных внедренцев, аргументирующих свои предложения высоконормализованными структурами данных - кто-то из клиентов таким может проникнуться??
А так бывает? Я думаю, что внедренец просто отойдёт от нормализации в пользу своего кармана. Ибо если в нормальном виде его система не удовлетворяет требования заказчика, то возникает вопрос "а нафига мы за ЭТО платим такие деньги?"

DogenМожно и пожертвовать, например, для обеспечения критичных требований по скорости выполнения запросов. Например, наличие таблицы остатков - классический пример не то что денормализации, а уж и не знаю как это у вас правильно называется.Какой чудный пример. Попробуйте-ка с такой таблицей выдать остатки по состоянию на прошлый день...

andbaryНормализация это всегда баланс! В зависимости от конкретной задачи этот баланс может быть разным!!!
Пример: Адрес клиента. Полностью нормализовав структуру вы доведете пользователей до белого каления (Выбирать из справочников все варианты).Здесь согласен. А если тот же самый адрес хранится не только в данных по клиенту, а ещё и в сч-фактурах, выписанных этому клиенту (копируется туда при создании фак-туры)? Пример натянутый, но принцип, думаю, понятен. Последствия, надеюсь, тоже.

Alexandr Kochmin
JV> Попробуйте-ка с такой
JV> таблицей выдать остатки по состоянию на прошлый день...
а в чем проблема-то?
текущие остатки надо видеть быстро -храним их специально.
Остатки на прошлое время вычисляем налету.
Проблема то в чем?В реализации. Могу привести (могу, но не буду) пример системы, в которой это реализовано совсем не так красиво и радужно, как Вы описали. И "на лету" - это не про ERP.

Я вообще не понимаю, как в системе, изначально предназначенной для ПЛАНИРОВАНИЯ ресурсов, легко и просто отображать остатки материалов на произвольную дату в прошлом. А ведь есть такое понятие, как бухгалтерские периоды, которые закрываются совсем не realtime...

gardenman>> В случае смены юрадреса просто появится новая строчка, а старый будет помечен как "блокированный".
А теперь представим, что что-то надо внести задним числом... И? Блокированный? Историю изменений хранить надо... :))Если Вы даёте пользователю возможность "что-то" вносить задним числом, то будьте готовы к тому, чтобы найти кто, когда, что, как и зачем внёс. Или разрешите эту функцию конкретному ответственному лицу. В любом случае это - разовая не стандартная операция и хранить ради неё адрес в каждом документе - просто не умно.