Что важно иметь в виду при проектировании базы данных? - PullRequest
18 голосов
/ 26 сентября 2008

Что важно иметь в виду при проектировании базы данных?

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

Ответы [ 23 ]

2 голосов
/ 14 ноября 2008

Я знаю, что это было заявлено, но нормализация, нормализация, нормализация - это ключ. Если есть случай, когда вы чувствуете, что по какой-то причине вам нужно хранить данные в ненормализованном формате, не делайте этого. Это должно быть обработано через представления или в отдельной базе данных отчетов. Мой другой ключевой совет - по возможности избегать текстовых / текстовых полей.

2 голосов
/ 22 июля 2009

«Правило большого пальца баз данных - вниз всегда бьет!»

Примеры: Если у вас есть таблица Customer со столбцами для почтового адреса, адреса доставки и платежного адреса ... Создайте отдельную таблицу CustomerAddress с типом адреса

Если у вас есть таблица CancellationDetails с CancellationReason01, CancellationReason02, CancellationReason03 .. создайте отдельную таблицу CancellationReason

1 голос
/ 26 сентября 2008

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

Предостережение заключается в том, чтобы сделать первичный ключ для каждой таблицы одним числовым столбцом (соответствующий вашему виду БД). В академической нормализации идея состоит в том, чтобы объединить любые атрибуты (столбцы) объекта (таблицы), чтобы вы могли однозначно идентифицировать экземпляр того, что описано (строка), и вы можете получить многокомпонентный составной первичный ключ , Таким образом, каждый раз, когда вы переносите этот составной ключ как внешний ключ в другие таблицы, вы в конечном итоге дублируете эти несколько столбцов в каждой таблице, которая ссылается на него. Это может работать для вас, если у вас есть только полдюжины столов. Но это быстро разваливается, когда вы идете намного больше этого.

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

1 голос
/ 26 сентября 2008

Если вы будете искать строки по полям, отличным от первичного ключа, обязательно их проиндексируйте.

1 голос
/ 26 сентября 2008

Понимайте требования настолько, насколько это возможно. Затем спроектируйте логическую схему, которая будет изменяться только при изменении требований или при переходе на совершенно другой тип базы данных, например, такую, которая не использует SQL. Затем доработайте и расширьте ваш дизайн до физического плана, который учитывает ваш конкретный продукт СУБД, ваш объем, вашу нагрузку и ваши требования к скорости.

Узнайте, как нормализовать, а также научиться нарушать правила нормализации.

1 голос
/ 26 сентября 2008

Это объектно-ориентированный язык? Поэтому попробуйте смоделировать ваши объекты перед базой данных. Это поможет вам сосредоточиться на модели.

1 голос
/ 26 сентября 2008

Если у вас есть запросы, которые вы собираетесь запустить много, превратите их в хранимые процедуры. Они будут почти всегда работать быстрее.

1 голос
/ 04 октября 2008

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

Это означает, что нужно выбирать имена, которые отражают реальность пользователей (но не бойтесь изменить их восприятие реальности, если это помогает модели).

Кодировать все ограничения, которые вы можете в базе данных. Не полагайтесь на прикладной уровень, чтобы предоставлять только разумные данные. Убедитесь, что в первую очередь могут существовать только разумные данные.

Не объединяйте данные в модели. Держите модель как можно более атомарной. Либо агрегируйте на лету, либо выполняйте обычные задания агрегации в таблицы агрегирования.

Выберите хороший раздел между схемами. Некоторое разделение имеет смысл делать с внешними ключами, а некоторые - чисто физическим разделением.

0 голосов
/ 26 сентября 2008

Я согласен, что знание о ваших данных является хорошим и нормализующим.

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

0 голосов
/ 26 сентября 2008

Не используйте большой набор столбцов в качестве первичных ключей

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...