Каковы наиболее важные соображения при разработке базы данных?

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

Это для начала

Ответ 2

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

Одна из самых важных вещей - не overarchitect.

Чтобы дать вам ответ с некоторыми зубами, позвольте взять "транспортное средство" в качестве примера. Автомобиль имеет несколько колес. У вас есть решающее решение узнать, что на автомобиле будет много колес. У вас есть 2 варианта: вы можете сделать "колеса" отдельным объектом, или вы можете сделать "количество колес" целочисленным полем в сущности "Vehicle".

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

Если нет, простое поле будет прекрасно.

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

Ответ 3

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

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

Примеры:

• Первичные ключи начинаются с IdTableName
• Обозначение имен таблиц - Pascal
• Внешние ключи - это TableNameId
• вн...

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

Базовый набор точек:

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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