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

Question

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

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

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

---

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

4. Схема звезда: размеры и факт, проект OLAP.

5. Полностью нормализованная конструкция OLTP.

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

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

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

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

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

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

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

Answer 4

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

Он описывает некоторые шаблоны баз данных .

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

вопросы:

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

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

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

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

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

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

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