Шаблоны Проектирования Реляционных Баз Данных?

вот ссылка на джентльмена, который разработал несколько сотен бесплатных схем баз данных.

http://www.databaseanswers.org/data_models/

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

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

шаблоны проектирования не являются тривиально многоразовыми решениями.

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

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

реляционные паттеры дизайна включают такие вещи, как:

1. отношения "один ко многим" (master-detail, parent-child) с использованием внешний ключ.

2. отношения "многие ко многим" с таблицей моста.

3. необязательные отношения "один к одному", управляемые с нулями в столбце FK.

4. звездная схема: измерение и факт, дизайн OLAP.

5. полностью нормализованный дизайн OLTP.

6. несколько индексированных столбцов поиска в измерении.

7. "таблица поиска", содержащая PK, описание и значения кода, используемые одним или несколькими приложениями. Зачем нужен код? Я не знаю, но когда они должны использоваться, это способ управления коды.

8. Uni-таблица. [Некоторые называют это анти-паттерном; это паттерн, иногда это плохо, иногда это хорошо.] Это таблица с большим количеством предварительно Соединенных вещей, которые нарушают вторую и третью нормальную форму.

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

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

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

и это не включает административные и операционные модели использования и управления.

проверьте этот блог - Программист Базы Данных.

Он описывает некоторые схемы БД.

книги Джо Челко отлично подходят для такого рода вещей, в частности "SQL для Smarties". У него есть несколько инновационных решений общих проблем, большинство из которых-многоразовые шаблоны проектирования.

http://www.celko.com/books.htm

AskTom является, вероятно, самым полезным ресурсом по лучшим практикам в Oracle DBs. (Обычно я просто набираю "asktom" в качестве первого слова запроса google по определенной теме)

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

сказав это, вы можете рассматривать "хранилище данных" как несколько отдельный "шаблон" или подход в дизайне базы данных. В частности, вам может быть интересно прочитать о Звезда-схемы.

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

вопросы:

• вы хотите использовать в будущем другую СУБД? Если да, то не использует специальный SQL-материал текущей СУБД. Удалите логику в приложении.

не использовать:

• пробелы в именах таблиц и столбцов имена
• не ASCII символов в именах таблиц и столбцов
• привязка к определенному нижнему регистру или верхнему регистру. И никогда не используйте 2 таблицы или столбца, которые отличаются только нижним и верхним регистром.
• не использует ключевые слова SQL для имен таблиц или столбцов, таких как" FROM"," BETWEEN"," DELETE " и т. д.

рекомендации:

• используйте NVARCHAR или эквиваленты для поддержки unicode, тогда у вас нет проблем с кодовая страница.
• дайте каждому столбцу уникальное имя. Это облегчает выбор столбца в join. Это очень сложно, если каждая таблица имеет столбец " ID "или" Name "или"Description". Используйте XyzID и AbcID.
• используйте пакет ресурсов или equals для сложных выражений SQL. Это облегчает переход на другую СУБД.
• не бросает жесткий на любой тип данных. Другой СУБД не может иметь этот тип данных. Например, у Oracle daes нет SMALLINT только a число.

Я надеюсь, что это хорошая отправная точка.

ваш вопрос немного расплывчатый, но я полагаю UPSERT можно считать шаблоном дизайна. Для языков, которые не реализуют MERGE, ряд альтернатив для решения проблемы (есть ли подходящие строки, UPDATE; else INSERT) существует.

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

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

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

BTW, S. Lott, один-ко-многим и отношения " многие ко многим "не являются"шаблонами". Они являются основными строительными блоками реляционной модели.

эта книга выглядит интересно

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5