Шаблоны проектирования реляционных баз данных?
https://stackoverflow.com/questions/145689
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Шаблоны проектирования обычно связаны с объектно-ориентированным проектированием.
Здесь шаблоны проектирования для создания и программирования реляционные базы данных?
Многие проблемы, несомненно, должны иметь многоразовые решения.
Примеры могут включать шаблоны проектирования таблиц, хранимые процедуры, триггеры и т. д.
Есть ли онлайн-хранилище таких шаблонов, похожее на marinfowler.com?
Примеры проблем, которые могут решить шаблоны:
- Хранение иерархических данных (например,одна таблица с типом и несколько таблиц с ключом 1:1 и различиями...)
- Хранение данных с переменной структурой (например.общие столбцы, XML и столбец с разделителями...)
- Денормализовать данные (как это сделать с минимальным воздействием и т. д.)
Решение
В фирменной серии Мартина Фаулера есть книга под названием Рефакторинг баз данных.Здесь представлен список методов рефакторинга баз данных.Не могу сказать, что я так часто слышал список шаблонов баз данных.
Я также очень рекомендую Дэвида К.Хэя Шаблоны моделей данных и последующие действия Карта метаданных который основан на первом и является гораздо более амбициозным и интригующим.Одно только предисловие поучительно.
Также отличным местом для поиска готовых моделей баз данных является серия книг Лена Сильверстона по моделям данных. Том 1 содержит универсально применимые модели данных (сотрудники, счета, доставка, покупки и т. д.), Том 2 содержит отраслевые модели данных (бухгалтерский учет, здравоохранение и т. д.), Том 3 предоставляет шаблоны моделей данных.
Наконец, хотя эта книга якобы посвящена UML и объектному моделированию, книга Питера Коада Цветное моделирование с помощью UML обеспечивает процесс моделирования сущностей, основанный на «архетипах», исходя из предпосылки, что существует 4 основных архетипа любой модели объекта/данных.
Другие советы
Вот ссылка на джентльмена, который разработал несколько сотен бесплатных схем баз данных.
http://www.databaseanswers.org/data_models/
Возможно, если вам нужно быстро создать базу данных, это даст вам отправную точку с точки зрения таблиц и отношений в данной схеме.Имейте в виду, что вам, вероятно, придется изменить эту отправную точку.Я нашел это очень полезным.
Во-вторых, в журнале SQL Server Magazine время от времени появляется колонка под названием «Разработчик моделей данных», которая очень поучительна и часто содержит полные схемы для данной системы.
Шаблоны проектирования не являются тривиальными решениями многократного использования.
Шаблоны проектирования можно использовать повторно по определению.Это шаблоны ты обнаружить в других хороших решениях.
Шаблон не является тривиальным для повторного использования.Однако вы можете реализовать свой дизайн пуха по шаблону.
Шаблоны реляционного проектирования включают в себя такие вещи, как:
Отношения «один-ко-многим» (основной-подробный, родительский-дочерний) с использованием внешнего ключа.
Отношения «многие ко многим» с промежуточной таблицей.
Необязательные отношения «один к одному», управляемые с помощью NULL в столбце FK.
Звездная схема:Измерение и факт, OLAP-проектирование.
Полностью нормализованный дизайн OLTP.
Несколько индексированных столбцов поиска в измерении.
«Таблица поиска», содержащая PK, описание и значения кода, используемые одним или несколькими приложениями.Зачем нужен код?Не знаю, но когда их приходится использовать, это способ управления кодами.
Юни-таблица.[Некоторые называют это антипаттерном;это шаблон, иногда он плохой, иногда хороший.] Это таблица с множеством предварительно объединенных элементов, которые нарушают вторую и третью нормальную форму.
Таблица массива.Это таблица, которая нарушает первую нормальную форму, поскольку в столбцах имеется массив или последовательность значений.
База данных смешанного использования.Это база данных, нормализованная для обработки транзакций, но с множеством дополнительных индексов для отчетности и анализа.Это антишаблон — не делайте этого.Люди все равно это делают, так что это все еще закономерность.
Большинство людей, проектирующих базы данных, могут легко отбарабанить полдюжины фраз: «Это еще одна из тех»;это шаблоны проектирования, которые они используют регулярно.
И это не включает в себя административные и эксплуатационные модели использования и управления.
Посмотрите этот блог - Программист баз данных.
Он описывает некоторые шаблоны баз данных.
Книги Джо Селко отлично подходят для такого рода вещей, в частности «SQL для умников».У него есть несколько инновационных решений распространенных проблем, большинство из которых представляют собой многократно используемые шаблоны проектирования.
СпросиТома это, вероятно, самый полезный ресурс по передовым практикам работы с базами данных Oracle.(Обычно я просто набираю «asktom» в качестве первого слова запроса Google по определенной теме)
Я не думаю, что уместно говорить о шаблонах проектирования реляционных баз данных.Реляционные базы данных уже представляют собой применение «шаблона проектирования» к проблеме (проблема заключается в том, «как представлять, хранить и работать с данными, сохраняя при этом их целостность», а проектирование представляет собой реляционную модель).Другими подходами (обычно считающимися устаревшими) являются навигационная и иерархическая модели (и я уверен, что существует множество других).
Сказав это, вы можете рассматривать «Хранилище данных» как несколько отдельный «шаблон» или подход к проектированию базы данных.В частности, вам может быть интересно прочитать о Схема звезды.
После многих лет разработки баз данных я могу сказать, что есть несколько вопросов и вопросов, на которые вам следует ответить, прежде чем начать:
вопросы:
- Хотите ли вы использовать в будущем другую СУБД?Если да, то не используется специальный SQL-материал текущей СУБД.Удалите логику в своем приложении.
Не использует:
- пробелы в именах таблиц и столбцов
- Символы, отличные от Ascii, в именах таблиц и столбцов.
- привязка к определенному нижнему или верхнему регистру.И никогда не используйте две таблицы или столбцы, которые различаются только строчными и прописными буквами.
- не использует ключевые слова SQL для имен таблиц или столбцов, таких как «FROM», «BETWEEN», «DELETE» и т. д.
рекомендации:
- Используйте NVARCHAR или его эквиваленты для поддержки Юникода, и тогда у вас не возникнет проблем с кодовыми страницами.
- Дайте каждому столбцу уникальное имя.Это облегчит выбор столбца при объединении.Это очень сложно, если в каждой таблице есть столбец «Идентификатор», «Имя» или «Описание».Используйте XyzID и AbcID.
- Используйте пакет ресурсов или его эквивалент для сложных выражений SQL.Это облегчит переход на другую СУБД.
- Не выполняет жесткое приведение к любому типу данных.Другая СУБД не может иметь этот тип данных.Например, у Oracle daes нет SMALLINT, только число.
Я надеюсь, что это хорошая отправная точка.
Ваш вопрос немного расплывчатый, но я полагаю UPSERT можно считать шаблоном проектирования.Для языков, которые не реализуют MERGE, несколько вариантов решения проблемы (если подходящие строки существуют, UPDATE;еще INSERT) существовать.
Зависит от того, что вы подразумеваете под шаблоном.Если вы думаете о человеке/компании/транзакции/продукте и тому подобном, то да – уже доступно множество общих схем баз данных.
Если вы думаете о Фабрике, Синглтоне...тогда нет - ничего из этого вам не нужно, поскольку они слишком низкого уровня для программирования БД.
Если вы думаете об именовании объектов базы данных, то это относится к категории соглашений, а не дизайна как такового.
Кстати, С.Лотт, отношения «один-ко-многим» и «многие-ко-многим» не являются «шаблонами».Они являются основными строительными блоками реляционной модели.
Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
