> Уважаемые архитекторы, проектировщики баз данных, поделитесь опытом, по какому
> принципу, личных соображений, исходите при выборе нормализации данных?

Всегда нормализуем.

Меньше
> редудантных данных обеспечивает компактное их хранение, возможно и скорость, но
> "усложняет" oбработку "join"-ов.

JOIN-ы -- не проблема для СУБД, проблема -- запросы без селективных фильтров.

10-30 join-ов в запросе -- ерунда, если запрос имеет нормальный фильтр, напр.
на 10-200 записей.

Денормализация- все в "одну табличку"- зато
> "один" select.

Дебилизм.

SERG1257 тут дал вполне адекватный взгляд на вещи.
Я добавлю ещё следующее: данные у нас защищены от ad-hoc запросов пользователей
(прямые запросы запрещены, даже на чтение, а уж тем более на изменение),
поэтому свою БД мы можем денормализировать в любое время. Но принципы такие:
-- Денормализация производится только для нужд улучшения производительности,
только в крайних случаях, когда по-другому уже не выкрутится.
-- денормализация -- это СНАЧАЛА нормализация, ПОТОМ следующий шаг. Не наоборот.
В БД ВСЕГДА остаются нормализованные данные и ТОЛЬКО ОНИ модифицируются.
Денормализованные поля проносятся при этом в (обычно дочерние) таблицы.

Пользователь естественно этого изменения данных никогда не видит.

Типичный случай денормализации -- это как я бы его назвал разнесённый
селективный ключ. Набор полей, используемый в запросе, имеющий высокую
селективность, но хранящийся в разных таблицах. Чтобы сделать по нему индекс,
поля одной таблицы копируются в другую.
Например, (КЛАСС ОБЪЕКТА, СОСТОЯНИЕ ОБЪЕКТА) хранились у нас в разных таблицах,
были сведены в одну в физической БД.

Posted via ActualForum NNTP Server 1.5

> В двух словах предысторию. Сделал шефу дизайн базы, следуя принципам
> нормализации. Шеф, он же хозяин фирмы, посмотрел, говорит, что хотел бы немного
> по-другому.

Если шеф смотрит в БД -- это уже мегастранно. Он не должен туда смотреть, его
должен интересовать только конечный результат.

Одним словом- для него редудантные данные- не проблема. И он, на
> самом деле предложил - все в одну табличку.


Для него -- не проблема. Это ТВОЯ проблема будет. Не его. А тебе он прикажет
"ЧТОБЫ ВСЁ БУЛО ОК" -- и всё. Ты будешь отдуваться, не он.

Скажем есть табличка с константными
> значиями, например, "тип самолета". Определенный "клиент" - может иметь,
> множество "типов самолетов". Вместо, чтобы содзавать таблицу
> "релатион_клиент_то_тип_самолета", предлагает, в самой табличке "клиент" создать
> поле "тип самолета", и в нем типы самолетов разделенные запятой. Тип поля


нарушение 1 НФ, ты не сможешь обрабатывать эти данные на SQL-е.
Очень грубая ошибка проектированич БДю

> varchar2(200byte) (oracle-db). Понятно, что в таких полях, при не совсем
> правильном использованием, возможно появления "мусора".

Дело даже не в этом.
Posted via ActualForum NNTP Server 1.5

> Я понимаю, что решение принимает шеф. Но какое и почему должны объяснить ему Вы.

Если за вас решение принимает шеф, надо увольняться.
Posted via ActualForum NNTP Server 1.5

> Как ни странно это не звучит, сейчас он смотрит в БД. Он, в принципе, как
> коллеги рассказывали, лично написал ранние версии продукта. Короче, последние
> пару лет, пара горе-архитекторов, с него так сказать денежки поимели, сделали
> ему "гавняшку". Их недавно уволили.
>

Если товарищь предлагает делать такое:
"Вместо, чтобы содзавать таблицу "релатион_клиент_то_тип_самолета", предлагает,
в самой табличке "клиент" создать поле "тип самолета", и в нем типы самолетов
разделенные запятой. Тип поля varchar2(200byte) (oracle-db)."

то он нифига не смыслит в базах данных однозначно, а соответственно слушать его
бессмысленно (в этом вопросе)

>
> >нарушение 1 НФ, ты не сможешь обрабатывать эти данные на SQL-е.
> >Очень грубая ошибка проектированич БДю
>
> референтных свойств, подобных "тип самолета", и привязанных к таблице "клиент",
> около 15 штук. Количество "join"-ов, при создании объекта в конечном приложении-
> возрастает до 20. С DBA-никами разговаривал на эту тему, нормализированный

Ты перепутал что-то, JOIN один, точнее два. От пользователя -- к типам самолётов
пользователя и потом куда уже надо с типами самолётов пользователя.

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

Это как ?

> MasterZiv, я Тебя павильно понимаю, что в данном случае лучше постараться еще и
> еще раз обьяснить шефу, что нормализированный вариант, будет одназначно лучше,

Он не будет однозначно лучше, он будет единственно правильным.
Другого варианта нет. Да, посторайся объяснить.

Ещё раз, такие дизайны БД -- это 100% вопиющая безграмотность проектировщика.

Ты можешь убедить шефа очень просто: создай прототип такой БД, маленький,
забей немного данных тестовых. И потом попробуй решить какую-то типовую
задачку с использованием типа самолёта пользвателя, напр, список всех рейсов
самолётов типов, записанных за данным пользователем
(НА SQL, РАЗУМЕЕТСЯ).

> даже при наличии множества референтных свойств, подобных "тип самолета" (ок.15)?
> И что "join"-ы особой проблемы на скорость предоставления данных не будут влиять?

JOIN-ы вообще для СУБД не проблема, хоть 200 их будет.
А скорость -- используешь индексы -- получаешь скорость пропорциональную
логарифму от размера таблицы. Посчитай сам. Логарифм возми напр. по основанию
10, хотя бы (в реальности основание больше).


Posted via ActualForum NNTP Server 1.5

> имеется ввиду следующее: продуктивно используется версия продукта, написанная
> несколько лет назад, где "тип_самолета" используется как поле. Пару лет назад,
> горе-арихтекторы "продали", так сказать, шефу идею про jpa. Существующую базу,

На самом деле обсуждать так какую -то БД смысла большого нет. Надо знать
постановку задачи, надо знать БД эту, структуру её.
Posted via ActualForum NNTP Server 1.5

> денормализацию стоит использовать только уже на очень больших объемах данных -
> мы начали где-то после 15гиг на одной табличке - доставить оборудования -> денег
> не выделяли

Наоборот, я бы сказал. Чем больше БД, тем актуальнее нормализованные данные.
Posted via ActualForum NNTP Server 1.5

> http://www.selikoff.net/2008/11/19/why-too-much-database-normalization-can-be-a-bad-thing/

Идиотская статья. В сети сейчас много идиотов, они все пишут статьи.
Точнее, конечно же, они не такие и идиоты -- деньги зарабатывают на рекламе на
своих сайтиках и бложиках.
Posted via ActualForum NNTP Server 1.5