Каковы наиболее важные соображения при разработке базы данных? - PullRequest
23 голосов
/ 24 февраля 2009

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

Ответы [ 12 ]

22 голосов
/ 24 февраля 2009

Прежде всего, и самое главное, изучите и поймите область бизнеса.

1) Вы смотрите на высокую скорость транзакций, например, на загруженный веб-сайт, или на низкое использование, как на HR-систему небольшой компании

2) Является ли безопасность большой проблемой - обрабатываете ли вы личные данные или финансовые данные. Или это просто каталог продукции

3) Будут ли ваши пользователи делать много обновлений / вставок, или это в основном только для чтения

4) Сколько пользователей, какие модели использования (пиковая нагрузка или равномерно распределенные)

5) Вам нужно круглосуточное, 16x5 или другое время безотказной работы, 24x7 гораздо сложнее, так как у вас нет простоев для обслуживания

6) Насколько большой будет БД? Если он действительно большой, вам придется спроектировать свои таблицы с учетом этого и / или раздела

7) Вам нужно посмотреть на корпоративный кластер с горячим переключением при сбое, или просто обычный хостинг

8) Как будет администрироваться БД, в большинстве проектов БД 95% усилий затрачивается на разработку для пользователей и их приложений, администратор БД забыт

9) DB Admin, из предыдущих включает резервные копии, изменения в других системах, интеграция с другими системами, загрузка данных

10) На самом деле загрузка данных и использование существующих данных - это еще одна серьезная проблема.

Вот и все для начала

16 голосов
/ 24 февраля 2009

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

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

Чтобы дать вам ответ с некоторыми зубами, давайте возьмем в качестве примера сущность «транспортное средство». Транспортное средство имеет несколько колес. Вы должны принять критическое решение, зная, что к автомобилю будет прикреплено несколько колес. У вас есть 2 варианта: вы можете сделать «колеса» отдельной сущностью или сделать «число колес» целочисленным полем в сущности «Автомобиль».

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

Если нет, простое поле отлично подойдет.

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

7 голосов
/ 24 февраля 2009

1 - Консистенция

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

Примеры:

  • Все первичные ключи начинаются с IdTableName
  • Корпус имен таблиц - Паскаль
  • Все внешние ключи - TableNameId
  • вн ...

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

Ваша база данных является последней линией защиты целостности данных. Доступ ко всем вашим данным осуществляется через хранимые процедуры и обеспечивает целостность данных с помощью проверочных ограничений, внешних ключей и так далее. Введите данные правильно, не используйте VARCHAR (50), когда CHAR (5) более конкретен и точен.

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

6 голосов
/ 24 февраля 2009

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

4 голосов
/ 24 февраля 2009

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

Я полагаю, что вы можете прочитать первую главу, если книгу через Google Книги или через предварительный просмотр страницы на Amazon.com.

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

2 голосов
/ 24 февраля 2009

Знай свои данные.

1 голос
/ 25 февраля 2009

Хорошую базу данных можно оценить следующим образом:

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

Другими словами, база данных является бизнесом. Если база данных не отражает, как работает бизнес, либо база данных неверна, либо бизнес ошибочен.

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

1 голос
/ 24 февраля 2009

Информационные требования являются наиболее важной частью.

Это еще один способ сказать "определить назначение вашей системы" из ответа, предоставленного CMS.

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

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

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

Но если у вас есть серьезные ошибки или упущения в ваших информационных требованиях, никакие умные разработки или реализации не смогут восполнить это.

1 голос
/ 24 февраля 2009

кто собирается его строить и поддерживать, где, как и с чем. Есть ли у вас методы, процедуры и процессы, чтобы сделать это или просто сделать это? Безусловно, бизнес-потребности управляют необходимыми данными, которые должны быть собраны в независимой от реализации ERD. Но вы также должны подумать о том, кто будет поддерживать данные с течением времени. Как и кто «владеет» данными. Кто владеет определениями сущностей и атрибутов.

1 голос
/ 24 февраля 2009

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

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