Правильная организация таблиц

[Avtopic]

Здравствуйте!
Прошу с терпением отнестись к длинному вопросу.

Допустим имеется таблица Т1. с полями п1, п2, п3,... п30.
п1 код изделия. В остальных перечислены атрибуты изделия
п2-п5 обязательные для каждого изделия.
остальные не обязательные
п6-п12 определяют размер вес и цвет
п13-п17 происхождение и т.п.
п18-п22 размещение на складе
п23-п30 дополнительные свойства.

Можно все это организовать в одной таблице. Но Можно Канешно, разделить на пять таблиц с полями
т1 п1-п5. т2 п1- п6-п12. т3 п1- п13-п17. т4 п1- п18-п22. т5 п1- п23-п30.

Я разделил, и вложил в это такой смысл:
Раз, не все поля могут заполняться у изделия, то думаю что, экономлю место.
т1 будет иметь все записи. таблицы т2-т5 только те в которых хотя бы один атрибут присутствует. т.е. т1 может иметь 1000000 записей а т5 0 потому что никогда не одно поле не было введено.
Минус всего этого то, что запроси удлинились и усложнились.

Вопрос такой: Во первых на сколько правильна такая логика.
и второе: допустим все поля в одной таблице, п1-п5 заполнены во всех записях, остальные пустые. Пожирают или нет пустые поля в записях то место, которое указано в типе поля.

Если все понятно передал, Спасибо за терпение и спасибо заранее!

[Никитка Б]

Ответ на второй вопрос. В FoxPro незаполненные поля все равно занимают место.

[Avtopic]

Ну, второй вопрос, наверно, вообще, зря задал, так как вероятность того, что пустые поля не занимают место, 0!

[Odrick]

Логика в целом неверная. Размер базы данных чаще всего не самое критичное место. Самое критичное место было есть и будет - скорость работы БД. В случае одной таблицы скорость отработки запросов на больших объемах данных будет на порядок выше, чем в реализованном варианте.

[Avtopic]

Спасибо за ответ.

Как раз эта сторона меня интересовала.

Не имея в этом опыта, бегаю по кругу: то объединяю, то разделяю,
не хочу допустить на стадии проектировки базы грубую ошибку.
Пока база маленькая. Смотрю, и так работает и этак, только запросы усложнились.

Думаю чего зря место терять. Встречал множество разговоров про накладные расходы связанное с хранением баз данных.
Вот и подумал что накладные расходы в первую очередь это занимаемое место на сервере.
Поэтому остановился на варианте разделения таблиц.
И таки продолжил бы, если б не ваш совет.

[Ennor]

Гугл -> "нормальная форма".

Третья ссылка очень даже ничего.

[Odrick]

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

[Al Khamid]

[Avtopic]

“количество записей о деталях” зависит от сезона.
Т.е. работа сезонная. В разгар у всех существует оправдательная причина, не заполнять поля с 6-ого по 30-ое,
ссылаются на отсутствие времени и эти поля как обычно пустые.
А когда затишье, то все поля по инструкции должны заполнятся по возможности максимально.
В среднем 70% в таблице пустует.

[Summer.05]

Вначале я делал разделенную таблицу. Все было хорошо, пока не вырос объем базы данных. Стала тормозить очень и очень даже. Я сделал одну таблицу, хотя это потом уже труднее. Теперь она очень большая, но скорость работы - несопоставимо выросла.
Тебе решать!