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

Question

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

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

Answer 1

"Нормализуй до боли; отмени нормализуй до работы."

Answer 2

(при условии OLTP)

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

http://en.wikipedia.org/wiki/Database_normalization

Answer 3

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

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

Answer 4

Убедитесь, что вы используете ограничения (CHECK, NOT NULL, FOREIGN KEY, PRIMARY KEY и DEFAULT), чтобы гарантировать, что в базе данных будут храниться только правильные данные. Вы всегда можете купить более быстрое оборудование, но вы не можете купить более правильные данные.

Answer 5

Попробуйте представить себе SQL-запросы, которые вы будете предварительно преобразовывать.

Это важно, потому что вы сделаете это много!

Answer 6

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

Да, подумайте о видах запросов и отчетов, которые вам понадобятся для запуска. Подумайте о расширяемости. Может показаться, что вам не нужно больше 10 столбцов продуктов в таблице заказов, но что происходит, когда вам нужно 11. Лучше иметь таблицу заказов и таблицу деталей заказов.

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

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

Следующая важная вещь - это защита и защита данных. Пользователи никогда не должны иметь прямого доступа к таблицам базы данных. Если ваш дизайн требует динамического SQL, он должен иметь такой доступ. Это плохо с точки зрения потенциального взлома с помощью таких вещей, как атаки с использованием SQL-инъекций, но, что еще более важно, это открывает вашу базу данных для мошенничества внутренних людей. Есть ли поля для шифрования данных? (информация о кредитной карте, пароли и номера социального страхования относятся к числу предметов, которые никогда не следует хранить в незашифрованном виде). Как вы планируете это делать и как вы планируете проводить аудит дешифрования, чтобы гарантировать, что люди не дешифруют, когда им не нужно просматривать данные. Есть ли какие-то законные обручи, через которые вы должны пройти ( HIPPA и Sarbanes Oxley приходят на ум)?

Answer 7

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

НЕ попадитесь в ловушку размещения столбцов идентификаторов на всех ваших таблицах. Есть много ОЧЕНЬ веских причин, почему современная теория проектирования баз данных использует реальные первичные ключи, и они не являются строго академическими причинами. Я работал с базами данных, которые включали в себя сотни таблиц, многие из которых были многомиллионными таблицами строк, с более чем 1000 одновременно работающих пользователей и с использованием реальных первичных ключей не «сломались».

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

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

Это давняя дискуссия, но это мое мнение по этому вопросу, для чего оно стоит.

Answer 8

Получите действительно хорошую книгу по моделированию данных - написанную настоящим разработчиком баз данных, а не разработчиком .NET, который пытается научить вас, как это делается в "реальном мире".

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

Послушайте вышеприведенные посты о нормализации. НИКОГДА не денормализуйте, потому что вы ДУМАЕТЕ, что вы должны по соображениям производительности. Вы должны денормализовать только после того, как у вас возникнут реальные проблемы с производительностью (в идеале в вашей среде QA, а не на производстве). Даже в этом случае подумайте, что может быть лучший способ написать ваши запросы или улучшить индексирование в первую очередь.

Максимально ограничьте данные. Столбцы должны быть НЕ NULL, насколько это возможно. Используйте ограничения CHECK и FOREIGN KEYs, где бы они ни были. Если вы этого не сделаете, плохие данные попадут в вашу базу данных и вызовут много головных болей и особых случаев программирования.

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

Answer 9

Данные вечны. Обработка приходит и уходит.

Получите реляционную модель, чтобы быть точным представлением реального мира. Это важнее всего на свете.

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

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

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

Answer 10

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

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

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