Что важно иметь в виду при проектировании базы данных?
Что важно иметь в виду при проектировании базы данных?
Я не хочу ограничивать ваш ответ моими потребностями, так как я уверен, что другие могут также извлечь выгоду из вашего понимания. Но я планирую систему управления контентом для сайта, управляемого сообществом клиентов.
23 ответа
"Нормализуй, пока не болит; не нормализуй, пока не заработает".
(Предполагая OLTP)
Нормализация ваших структур данных. (Денормализация производительности, как правило, может следовать позже, где это необходимо)
Убедитесь, что вы используете ограничения (CHECK, NOT NULL, FOREIGN KEY, PRIMARY KEY, а также DEFAULT) чтобы гарантировать, что только правильные данные хранятся в базе данных в первую очередь. Вы всегда можете купить более быстрое оборудование, но вы не можете купить более правильные данные.
Установите последовательные стандарты именования заранее. Это сэкономит несколько минут ненужного мышления в долгосрочной перспективе. (Это может выглядеть как ирония, но я серьезно.)
И не сокращайте ничего, если это не очень распространено. Не превращайте базу данных в игру с угадыванием сообщений номерного знака. Удивительно, что становится неочевидным через год.
Попробуйте представить себе SQL-запросы, которые вы будете предварительно обрабатывать.
Это важно, потому что вы будете делать это много!
Некоторые вещи, которые я хотел бы иметь в виду. Убедитесь, что в каждой таблице есть способ уникальной идентификации записей (вы сэкономите на этом неисчислимые часы боли). Нормализуйте, но не объединяйте большие многостолбцовые естественные ключи, если вы не хотите, чтобы все было медленно. Вместо этого используйте цифровой ключ, который автоматически создается в родительской таблице.
Да, подумайте о видах запросов и отчетов, которые вам понадобятся для запуска. Подумайте о расширяемости. Может показаться, что вам не нужно больше 10 столбцов продуктов в таблице заказов, но что происходит, когда вам нужно 11. Лучше иметь таблицу заказов и таблицу деталей заказов.
Убедитесь, что все правила целостности данных включены в базу данных. Не все изменения данных происходят из пользовательского интерфейса, и мне пришлось попытаться исправить слишком много плохо испорченных баз данных, потому что дизайнеры решили, что все правила можно поместить в графический интерфейс.
Наиболее важные вещи, которые необходимо учитывать при проектировании, это, во-первых, как обеспечить целостность данных (если данные бессмысленны, тогда база данных бесполезна), и, во-вторых, как обеспечить производительность. Не используйте объектную модель для проектирования реляционной базы данных, если вы не хотите плохой производительности.
Следующая самая важная вещь - защита данных и безопасность. Пользователи никогда не должны иметь прямого доступа к таблицам базы данных. Если ваш дизайн требует динамического SQL, он должен иметь такой доступ. Это плохо с точки зрения потенциального взлома с помощью таких вещей, как атаки с использованием SQL-инъекций, но, что еще более важно, это открывает вашу базу данных для мошенничества внутренних людей. Существуют ли поля, в которых необходимо зашифровать данные (информация о кредитной карте, пароли и номера социального страхования входят в число элементов, которые никогда не следует хранить в незашифрованном виде). Как вы планируете это делать и как вы планируете проводить аудит дешифрования, чтобы гарантировать, что люди не дешифруют, когда им не нужно просматривать данные. Есть ли какие-то юридические проблемы, через которые вы должны пройти ( HIPPA и Сарбейнс Оксли приходят на ум)?
Данные вечны. Обработка приходит и уходит.
Получите реляционную модель, чтобы быть точным представлением реального мира. Это важнее всего на свете.
Обработка будет меняться и развиваться годами. Но ваши данные - и модель данных - не могут развиваться с одинаковой скоростью и с одинаковой гибкостью. Вы можете добавить обработку, но вы не можете волшебным образом добавить информацию. Вы не хотите удалять информацию (но вы можете игнорировать ее.)
Получите модель правильно. Сущности и отношения в ваших диаграммах должны иметь рациональный смысл для случайного нетехнического пользователя. Даже прикладное программирование должно быть простым, понятным и точным.
Если вы боретесь с моделью, не изобретайте большие, сложные запросы или (что еще хуже) хранимые процедуры, чтобы обойти проблемы. Процедурные обходные пути являются дорогостоящей ошибкой. Поймите, что у вас есть, что вы хотите сделать, и применяйте принцип YAGNI, чтобы свести вещи к основам.
Получите действительно хорошую книгу о моделировании данных - написанную настоящим разработчиком баз данных, а не разработчиком.NET, который пытается научить вас, как это делается в "реальном мире".
Проблемное пространство дизайна базы данных слишком велико, чтобы его можно было охватить таким форумом. Несмотря на это, я дам вам несколько личных указателей:
Послушайте вышеприведенные посты о нормализации. НИКОГДА не денормализуйте, потому что вы ДУМАЕТЕ, что вы должны по соображениям производительности. Вы должны денормализовать только после того, как у вас возникнут реальные проблемы с производительностью (в идеале в вашей среде QA, а не на производстве). Даже в этом случае подумайте, что может быть лучший способ написать ваши запросы или улучшить индексирование в первую очередь.
Ограничьте данные как можно больше. Столбцы должны быть НЕ NULL, насколько это возможно. Используйте ограничения CHECK и ЗАРУБЕЖНЫЕ КЛЮЧИ, где бы они ни были. Если вы этого не сделаете, плохие данные попадут в вашу базу данных и вызовут много головных болей и особых случаев программирования.
Продумайте свои данные, прежде чем приступить к разработке таблиц. Получите хорошее представление о том, как будут проходить ваши процессы и какие данные им нужно будет отслеживать. Часто то, что вы считаете сущностью на первый взгляд, оказывается двумя сущностями. Например, в системе, над которой я работаю, предыдущий дизайнер создал таблицу Member, и вся информация из их приложения была частью таблицы Member. Оказывается, что участник может захотеть изменить данные, которые были в его приложении, но нам все равно нужно отслеживать, как выглядело исходное приложение, так что приложение действительно является его собственной сущностью, а член является сущностью, которая может быть первоначально заполнена из приложение. Короче говоря, проводите обширный анализ данных, а не просто начинайте создавать таблицы.
Поскольку было несколько сообщений, пропагандирующих это сейчас, я добавлю еще одну вещь...
НЕ попадайтесь в ловушку размещения столбцов идентификаторов на всех ваших таблицах. Есть много ОЧЕНЬ веских причин, почему современная теория проектирования баз данных использует реальные первичные ключи, и они не являются строго академическими причинами. Я работал с базами данных, которые включали в себя сотни таблиц, многие из которых были многомиллионными таблицами строк, с более чем 1000 одновременных пользователей и использованием реальных первичных ключей не "сломались".
Использование столбцов идентификаторов во всех ваших таблицах означает, что вам придется выполнять объединения нескольких таблиц, чтобы перемещаться по базе данных, что становится большой проблемой. Это также способствует неаккуратному проектированию баз данных и даже за его пределами, что часто приводит к проблемам с дублирующимися строками. Другая проблема заключается в том, что при работе с внешними системами вам теперь приходится обмениваться этими идентификаторами.
Существуют места для суррогатных идентификаторов - таблицы кодов типов и концептуальные таблицы (например, таблица системных правил может использовать идентификатор, если правила не имеют реальных идентификаторов). Использование их везде - ошибка ИМО.
Это давняя дискуссия, но это мое мнение по этому вопросу, для чего оно стоит.
Я знаю, что это было заявлено, но нормализация, нормализация, нормализация - это ключ. Если есть случай, когда вы чувствуете, что по какой-то причине вам нужно хранить данные в ненормализованном формате, не делайте этого. Это должно быть обработано через представления или в отдельной базе данных отчетов. Мой другой ключевой совет - по возможности избегать текстовых / текстовых полей.
"Правило большого пальца баз данных - вниз всегда лучше!"
Примеры: если у вас есть таблица Customer со столбцами для почтового адреса, адреса доставки и адреса выставления счета... создайте отдельную таблицу CustomerAddress с типом адреса
Если у вас есть таблица CancellationDetails с CancellationReason01, CancellationReason02, CancellationReason03.. создайте отдельную таблицу CancellationReason
Будь практичным. Имейте в виду, каковы ваши цели и не сходите с ума, создавая ненужные сложности. У меня есть некоторые предпочтения:
- Держите количество столов маленьким
- предпочитайте узкие таблицы широким, заполненным нулевыми значениями.
- Нормализация вообще хорошая
- Триггеры, как правило, очень болезненные
Но это средство для достижения цели (и во многих случаях они противоречивы и требуют тщательной балансировки), главное, чтобы требования определяли дизайн. Ваш выбор того, что является отдельной сущностью, и что является частью другой сущности, и что такое корм для кошек (а не то, чья личность вас интересует) полностью зависит от ваших требований.
Поймите требования настолько, насколько вы можете заранее. Затем спроектируйте логическую схему, которая будет изменяться только при изменении требований или при переходе на совершенно другой тип базы данных, например, не использующий SQL. Затем доработайте и расширьте ваш дизайн до физического, который учитывает ваш конкретный продукт СУБД, ваш объем, вашу нагрузку и ваши требования к скорости.
Узнайте, как нормализовать, а также узнать, когда нарушать правила нормализации.
Я полностью повторяю, что нормализация имеет решающее значение, с тактической денормализацией, которой необходимо следовать для обеспечения производительности или других причин ремонтопригодности. Однако, если вы ожидаете иметь больше, чем несколько таблиц, я хотел бы предложить одно предупреждение о нормализации, которое значительно облегчит вашу жизнь по мере роста количества таблиц.
Предостережение заключается в том, чтобы сделать первичный ключ для каждой таблицы одним числовым столбцом (соответствующий вашему вкусу БД). В академической нормализации идея состоит в том, чтобы объединить любые атрибуты (столбцы) сущности (таблицы), чтобы вы могли однозначно идентифицировать экземпляр того, что описано (строка), и вы можете получить многокомпонентный составной первичный ключ, Таким образом, всякий раз, когда вы переносите этот составной ключ как внешний ключ в другие таблицы, вы в конечном итоге дублируете эти несколько столбцов в каждой таблице, которая ссылается на него. Это может работать для вас, если у вас есть только полдюжины столов. Но это быстро разваливается, когда вы идете намного больше, чем это.
Поэтому вместо составного первичного ключа, состоящего из нескольких столбцов, используйте последовательный числовой первичный ключ, хотя этот подход противоречит некоторым строгим правилам нормализации.
Если у вас есть запросы, которые вы собираетесь запустить много, превратите их в хранимые процедуры. Они почти всегда бегут быстрее.
Если вы будете искать строки по полям, отличным от первичного ключа, обязательно внесите их в указатель.
Убедитесь, что в модели закодировано как можно больше метаданных. Должна быть возможность вывести практически любое бизнес-правило или концепцию из простого взгляда на модель данных.
Это означает, что вы должны выбирать имена, которые отражают реальность пользователей (но не бойтесь изменить их восприятие реальности, если это помогает модели).
Закодируйте все ограничения, которые вы можете в базе данных. Не полагайтесь на прикладной уровень только для предоставления разумных данных. Убедитесь, что только разумные данные могут существовать в первую очередь.
Не объединяйте данные в модели. Держите модель как можно более атомарной. Либо объединяйте на лету, либо выполняйте регулярные задания по объединению в таблицы агрегирования.
Выберите хороший раздел между схемами. Некоторое разделение имеет смысл делать с внешними ключами, а некоторые чисто физическим разделением.
Это объектно-ориентированный язык? Поэтому попробуйте смоделировать ваши объекты перед базой данных. Это поможет вам сосредоточиться на модели.
Не используйте большой набор столбцов в качестве первичных ключей.
Я бы сказал, что важно помнить, что структура может измениться. Так что не загоняй себя в угол. Убедитесь, что все, что вы делаете, оставляет вам некоторую "комнату" и даже возможность для переноса данных в другую структуру.
Я согласен, что знание о ваших данных хорошо и нормализует.
Что-то еще, что я хотел бы предложить, - хранить очень большие текстовые поля в отдельной таблице. Например, если у вас есть контракт, вы, возможно, захотите хранить большую часть информации о контракте в одной таблице, но сохранить юридический (и очень большой) документ в отдельной таблице. Просто вставьте указатель из основной таблицы в юридический документ.
Помните, что нормализация относится только к тому, что вы моделируете. Возможно, вы моделируете коллекцию объектов в вашем домене. Возможно, вы записываете серию событий, в которых данные повторяются, потому что одни и те же данные применяются более чем один раз. Не путай две вещи.
Столько, сколько вы можете сделать первичный ключ порядковым номером.