Рекомендации по дизайну базы данных

Ответ 1

Несколько точек:

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

Ответ 2

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

См., например, книги Фаулера о шаблонах проектирования. Также Nock Book.

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

Здесь есть книга IEEE, На основе проектирования и реализации баз данных на основе шаблонов.

Поисковая система Google () показала 24M-образы.

Ответ 3

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

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

Мой совет: не покупайте его.

В действительности, актив - это способность компании ВЗАИМОДЕЙСТВОВАТЬ с данными. Чтобы просмотреть его, управлять им и принимать решения на его основе.

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

Это означает, что я сосредоточу основное внимание на создании эффективного пользовательского интерфейса, а не на "разработке идеальной базы данных". База данных - это просто инструмент, который позволяет вам выполнять пользовательский интерфейс.

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

Это делает структуру базы данных чрезвычайно гибкой.

Попытка создать базу данных "гибкой в ​​будущем" или "оптимизировать производительность" - это в основном потраченное впустую действие.

Изменение структуры базы данных будет иметь относительно небольшое влияние на вашу систему.

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

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

Итак, я бы рекомендовал вам:

• Просто создайте дрянной дизайн БД
• Реагировать на реальные сценарии производительности, с которыми вы сталкиваетесь
• Сосредоточьтесь на опыте пользователя, а не в базе данных.

Ответ 4

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

Откажитесь от Google и найдите "MUCK Tables", которые приведут вас к обсуждению таблиц с массовым унифицированным кодом. Кроме того, вы можете искать "одну истинную таблицу поиска" для обсуждения. Или даже прочитайте статью Джо Селко Одна таблица True Lookup.

Ответ 5

Как и во всем, ответ здесь: "Это зависит".

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

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

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

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

Ответ 6

Лучшая книга, которую я когда-либо читал в отношении дизайна базы данных, - "Дизайн базы данных для простых смертных" Майкла Дж. Эрнандеса. Название звучит как книга для новичков, но люди на любом уровне могут получить от этого знания. Он также независим от платформы, поскольку он занимается рассмотрением самих данных и их правильной организацией, а не используемой технологией.

Он также написал книгу о написании запросов под названием "SQL Queries for Mere Mortals", которые я слышал (еще не прочитал) сам по себе неплохо.

Дизайн базы данных для простых смертных

Ответ 7

Не сохраняйте вычисленные значения

Пример. У вас есть таблица "Квадраты" со столбцом "ширина". Не нужно создавать столбцы "area", потому что это можно вычислить по ширине ^ 2

Ответ 8

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

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

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

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

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

Ответ 9

Я не нашел то, что искал в этом вопросе, но этот имеет кучу рекомендаций для дизайна шаблонов в дизайне БД

Ответ 10

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

Ответ 11

если вы не документируете перечисления в столбце описания схемы, чтобы я мог понять, что такое "5":

Select name from peeps where accountStatusId = 5

, тогда сделайте это

Используйте таблицу для перечисления поля. например:

Select name 
from peeps p 
join accountStatus s 
on p.accountStatusID = s.asid 
where s.accountStatus = 'ActiveDude'

Ответ 12

Книга Майкла Дж. Эрнандеса Дизайн базы данных для простых смертных хорошо написана и легко читается. Он должен ответить на все ваши вопросы.

Эрнандес также соавтор SQL запросов для простых смертных с Джоном Л. Viescas.

Книги составляют около 60 долларов за штуку. Я пытаюсь найти компакт-диск для запросов для простых смертных, потому что я потерял свой. Если у кого есть копия, дайте мне знать.

Ответ 13

Я бы сказал, что до тех пор, пока база данных будет нормализована, и если вы создадите VLDB, тогда ее правильно разделите, тогда все будет хорошо. другие лучшие практики включают использование CRUD для хранимых процедур и обеспечение правильного каскадирования всех таблиц. большинство всего остального субъективно. Использование "Y/N" - это программирование старой школьной базы данных с того момента, когда бит еще не введен. Его также можно использовать для целей масштабирования, таких как "Y/N/Maybe", но если бы это было так, то практика bast скажет, чтобы нормализовать это и сделать таблицу поиска.

Ответ 14

Одна концепция, которую мы используем здесь, которая оказалась довольно приятной, - это таблица "Lookup Code". Если у вас есть база данных, в которой есть много ссылок на элементы, которые эффективно кодов или типов, или т.п., Сохраните их все в одной таблице LookupCode, которая основывает свои функции на CodeGroup и самом коде.

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

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