Рекомендации по проектированию баз данных [закрыто]

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

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

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

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

Поиск Google (ссылке) оказалось 24M хитов.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. просто произведите дерьмовый дизайн БД
2. реагировать на фактические сценарии производительности вы сталкиваетесь
3. сосредоточьте свои усилия на пользовательском опыте, а не на базе данных

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

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

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

Как и в любом случае, ответ здесь: "это зависит."

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

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

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

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

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

Он также написал книгу о написании запросов под названием "SQL-запросы для простых смертных", которые я слышал (не читал этот сам пока) вполне хорош.

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

Не хранить вычисляемые значения

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

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

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

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

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

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

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

Если вы не документируете перечисления в столбце описания схемы, чтобы я мог понять, что такое " 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'

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

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

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

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

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

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

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