Шаблоны проектирования реляционных баз данных? [закрыто]

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

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

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

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

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

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

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

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

Наконец, в то время как эта книга якобы посвящена UML и объектному моделированию, моделирование Питера Коада в цвете с помощью UML предоставляет процесс моделирования сущностей, управляемый «архетипом», исходя из того, что существует 4 основных архетипа любой модели объекта / данных.

Шаблоны проектирования - это не тривиальные решения.

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

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

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

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

2. Отношения «многие ко многим» с таблицей мостов.

3. Необязательные отношения «один к одному», управляемые с помощью NULL в столбце FK.

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

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

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

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

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

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

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

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

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

AskTom - это, пожалуй, самый полезный ресурс по передовым методам работы с БД Oracle. (Я обычно просто набираю "asktom" в качестве первого слова запроса Google по определенной теме)

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

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

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

вопросы:

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

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

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

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

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

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

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

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

Если вы думаете о Factory, Singleton ... тогда нет - вам не нужно ничего из этого, поскольку они слишком низкого уровня для программирования БД.

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

Кстати, С. Лотт, отношения «один ко многим» и «многие ко многим» не являются «образцами». Они являются основными строительными блоками реляционной модели.