Реляционные шаблоны проектирования баз данных?

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

Примеры включают шаблоны для проектирования таблиц, хранимых процедур, триггеров и т.д.

Существует ли онлайн-хранилище таких паттернов, похожее на martinfowler.com?

Примеры проблем, которые могут решить шаблоны:

  • Сохранение иерархических данных (например, одна таблица с типом vs с несколькими таблицами с ключом 1:1 и различиями...)
  • Сохранение данных с переменной структурой (например, общие столбцы против столбца xml vs с разделителями)
  • Денормализовать данные (как это сделать с минимальным воздействием и т.д.)

Ответы

Ответ 1

Там есть книга в серии подписи Мартина Фаулера под названием Рефакторинг баз данных. Это дает список методов рефакторинга баз данных. Я не могу сказать, что я слышал список шаблонов баз данных.

Я также очень рекомендую David C. Hay Шаблоны модели данных и последующие Карта метаданных, которая основывается на первой и гораздо более амбициозной и интригующей. Предисловие само по себе является просветляющим.

Также отличное место для поиска некоторых предварительно подготовленных моделей баз данных - это серия книг ресурсов ресурса Len Silverston Том 1 содержит универсально применимые модели данных (сотрудники, учетные записи, отправка, покупки и т.д.), Том 2 содержит отраслевые модели данных (учет, здравоохранение и т.д.), Том 3 предоставляет модели модели данных.

Наконец, хотя эта книга якобы о UML и объектном моделировании, Peter Coad Modeling in Color With UML обеспечивает "управляемый архетипом" процесс сущность моделирования, исходя из предпосылки, что существует 4 основных архетипа любой модели объекта/данных.

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

  • Связи Many-to-Many с таблицей моста.

  • Дополнительные отношения "один-к-одному", управляемые с помощью NULL в столбце FK.

  • Star-Schema: измерение и факт, дизайн OLAP.

  • Полностью нормализованный проект OLTP.

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

вопросы:

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

Не используется:

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

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

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

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

Ответ 8

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

Ответ 9

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

Если вы думаете, что Factory, Singleton... then no - вам не нужны какие-либо из них, поскольку они слишком низки для программирования DB.

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

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