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

Question

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

Вот это для начала

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Одна из самых важных вещей, чтобы сделать, это не overarchitect.

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

Знайте ваши данные.

Answer 8

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

Answer 9

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

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

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

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

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

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

Answer 10

1 - Последовательность

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

Примеры:

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

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

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

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

Answer 11

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

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

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

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

Answer 12

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