Как вы подходите к дизайну базы данных? [закрыто]

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

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

Итак, как вы подходите к базе данных с точки зрения веб-приложения? Как вы начинаете и на что обращаете внимание? Какие флаги для осторожности?

Лучшая книга о дизайне баз данных, которую я купил баз данных, которую Разработка баз данных для простых смертных» Майкла Эрнандеса. ISBN: 0-201-69471-9. Листинг Amazon Я заметил, что у него третье издание.

Ссылка на третье издание

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

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

В программировании у вас есть:

• Если строит
• Если еще строит
• Делай пока петли
• Делать до цикла
• Case Constructs

С базами данных у вас есть:

• Таблицы данных
• Таблицы поиска
• Отношения один на один
• Отношения один ко многим
• Отношения многие ко многим
• Первичные ключи
• Внешние ключи

Чем проще ты делаешь вещи, тем лучше. База данных - это не что иное, как место, где вы помещаете данные в ямы. Начните с определения того, что это за дырки в кубиках, и какие вещи вы в них хотите.

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

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

Я занимаюсь как объектно-ориентированным программированием, так и (в основном транзакционным, но немного OLAP) проектированием баз данных, и в моих обстоятельствах есть много повторяющихся тем (по крайней мере, с OLTP).

Практика нормализации 3nf помогает мне практиковать некоторый вариант принципа единой ответственности. Таблица должна представлять концепцию в вашей системе - и концепции должны относиться друг к другу так, чтобы они пытались имитировать реальность; например, если я создаю систему, в которой у Клиента может быть 0 или много действий, я создаю таблицу клиентов и таблицу действий. Таблица действий имеет отношение внешнего ключа к таблице Customer. Когда я создаю хранимые процедуры, я обязательно использую внешнее объединение, чтобы присоединиться к Клиенту и деятельности, потому что бизнес-требование, чтобы у Клиента могло быть 0 действий.

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

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

Сначала я создаю схему базы данных, а затем использую ORM для создания объектов из нее. Я немного староват. Я не доверяю ORM создавать интеллектуальную, эффективную схему базы данных. Это работа людей и часть мастерства разработки программного обеспечения.

Я нашел книгу Билла Карвина «Антипаттерны SQL» очень полезной для планирования баз данных. Смысл, который она подчеркивает наиболее полно, заключается в том, что база данных предлагает множество возможностей для защиты целостности и значимости ваших данных, и что дизайнеры часто ошибочно игнорируют эти функции по разным соблазнительным причинам. Рассмотрение этих проблем с самого начала и предоставление им информации обо всем проекте имеет смысл и лучше, чем пытаться покрыть трещины позже.

Я предпочитаю использовать базу данных, которая имеет всеобъемлющие ограничения для обеспечения бизнес-логики и целостности на уровне базы данных. Часто я вижу базу данных как приложение и все, что обращается к ней как простой интерфейс. Это делает добавление других «интерфейсов» более приятным и понятным и имеет положительные преимущества для безопасности.

Я также думаю, что важно рассматривать структуру базы данных как изменяющуюся сущность, а не предполагать, что вам нужно обернуть ее и запечатать, прежде чем начинать что-либо еще. Вы должны планировать изменения и разместить БД в своей системе управления версиями. На это есть хорошее эссе: « Эволюционный дизайн базы данных» Мартина Фаулера и Прамода Садаладжа (а также целая книга по этому вопросу, написанная Садаладжем, хотя я этого не читал).

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

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

• написать короткие предложения, фиксирующие отношения между сущностями
• нарисовать диаграмму отношения сущность, представляющую предложения
• создать нормализованную логическую модель данных из диаграммы ER
• сделать CRUD-матрицу для приложений и сущностей
• использовать матрицу для проверки охвата жизненного цикла каждого объекта
• извлекать подсхемы для каждого приложения
• изучить пути навигации по подсхемам для каждой основной операции / CRUD
• рассмотреть отчеты, которые будут необходимы
• разработать физическую модель данных на основе всего вышеперечисленного; денормализовать, разделить и использовать звездообразные схемы, где это уместно

Чтобы успешно спроектировать базу данных, вам нужно сначала рассмотреть несколько вещей:

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

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

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

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

Также полезно немного прочитать о рефакторинге баз данных, прежде чем начать, так как позже потребуется рефакторинг, и полезно знать, как все настроить, чтобы вы могли реорганизовать как можно проще.

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

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

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

С точки зрения построения достойной модели - у @Tim она есть для базы данных, и фундаментальное построение вашей объектной модели будет во многом схожим - что уникально, что такое иерархия, где много-много связей и т. Д., Тогда, однако, вы доберитесь до базы данных, убедитесь, что вы делаете все хорошее.

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

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

В конце концов, если модель станет слишком большой, я перенесу ее в Visio и поработаю над деталями на доске.

Последнее я думаю о точках расширения. Самая большая ошибка, которую я вижу, делает большинство людей, проектирует свою базу данных, а затем говорит: «Я закончил с базой данных» и продолжаю. Вы никогда не сделали с базой данных. Каждый полученный вами запрос на изменение, вероятно, будет проходить вплоть до этого уровня. Так что подумайте, как добавить к этому. Подумайте о том, какие запросы возможны, и посмотрите, сможете ли вы их подключить. Если вы вообще не задумываетесь о расширяемости, вы столкнетесь с серьезным долгом проектирования, когда появятся эти запросы на изменение.

Что касается «SQL, то ORM» или наоборот, вам решать. Просто убедитесь, что ваша модель в первую очередь является хорошей основой.

Сначала я создаю объекты, затем использую ORM (например, nHibernate) для создания схемы. Это дает мне больше гибкости, чем обратное.

Следующим шагом является оптимизация сгенерированной схемы.

Прошло много времени с тех пор, как я видел проект, в котором сначала были созданы таблицы базы данных.

Немногие вещи, о которых другие участники прямо не заявили:

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

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

• Знать, какой код делать в программах и какой код разрешить БД. Это необходимо для правильной установки пустого столбца данных, а не нуля и т. Д. Это также необходимо, чтобы вы правильно указали свой RI.

• Хорошо определите свои первичные ключи. Пойдите для простых ключей, когда можете.

• Учитывайте необходимость интеграции с другими приложениями.

• Подумайте об использовании универсальных моделей данных и следуйте отраслевым стандартам в отношении именования и размера столбцов данных.

• Подумайте о будущих потребностях (когда это известно и когда применимо)

• Проверьте ваш режим другими.

• Используйте инструмент для моделирования - либо инструмент ERD, либо инструмент UML.

• Просмотрите и поймите сгенерированный код DDL. Не принимайте это как должное.