Шаблони дизайну реляційних баз даних? [зачинено]

Шаблони дизайну зазвичай пов'язані з об'єктно-орієнтованим дизайном.
Чи існують шаблони проектування для створення та програмування реляційних баз даних ?
Багато проблем, безумовно, повинні мати рішення для багаторазового використання.

Приклади включають шаблони для дизайну таблиць, збережених процедур, тригерів тощо ...

Чи є в Інтернет сховищі подібних шаблонів, схожих на martinfowler.com ?

Приклади проблем, які можуть вирішити шаблони:

• Зберігання ієрархічних даних (наприклад, одна таблиця з типом проти кількох таблиць з клавішем 1: 1 та відмінностями ...)
• Зберігання даних із змінною структурою (наприклад, загальні стовпці проти xml проти обмеженого стовпця ...)
• Денормалізувати дані (як це зробити з мінімальним впливом тощо)

У серії підписів Мартіна Фаулера є книга " Бази даних рефакторингу" . Це надає перелік методів рефакторингу баз даних. Не можу сказати, що я так багато чув список моделей баз даних.

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

Також чудовим місцем для пошуку деяких попередньо консервованих моделей баз даних є серія книг Лен Сілверстона «Книга ресурсів книги серії» том 1 містить загальноприйняті моделі даних (співробітники, рахунки, доставка, покупки тощо). Том 2 містить конкретні галузеві моделі даних (бухгалтерський облік, охорона здоров’я тощо), у томі 3 наведено моделі моделей даних.

Нарешті, хоча ця книга нібито про UML та моделювання об'єктів, моделювання Пітера Кода в кольорі за допомогою UML забезпечує "архетипний" процес моделювання сутності, починаючи з того, що існує 4 основні архетипи будь-якої моделі об'єкта / даних.

Шаблони дизайну - це не тривіально багаторазові рішення.

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

Візерунок не є тривіально використаним. Однак ви можете реалізувати свій нижній дизайн за зразком.

Реляційні дизайни включають такі речі, як:

1. Відносини "один до багатьох" (майстер-деталь, батько-дитина) стосунки із використанням іноземного ключа.

2. Взаємовідносини "багато до багатьох" з мостовим столом.

3. Необов’язкові взаємовідносини один на один, керовані NULL, у колонці FK.

4. Зірка-схема: розмір і факт, дизайн OLAP.

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

6. Кілька індексованих пошукових стовпців у вимірі.

7. "Таблиця пошуку", яка містить ПК, опис та значення коду, які використовуються одним або кількома додатками. Чому код? Я не знаю, але коли їх потрібно використовувати, це спосіб управління кодами.

8. Уні-стіл. [Деякі називають це анти-зразком; це шаблон, іноді це погано, іноді добре.] Це таблиця з великою кількістю попередньо з’єднаних речей, що порушує другу та третю нормальну форму.

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

10. База даних змішаного використання. Це база даних, нормалізована для обробки транзакцій, але з великою кількістю додаткових індексів для звітування та аналізу. Це анти-шаблон - не робіть цього. Люди так чи інакше роблять, тож це все-таки закономірність.

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

І це не включає адміністративні та експлуатаційні структури використання та управління.

AskTom - це, мабуть, єдиний найкорисніший ресурс щодо найкращих практик роботи з Oracle DB. (Я зазвичай просто набираю "asktom" як перше слово запиту google на певну тему)

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

Сказавши це, ви можете розглянути "зберігання даних" як дещо окремий "шаблон" або підхід у дизайні бази даних. Зокрема, вам може бути цікаво прочитати про схему Зірка .

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

питання:

• Ви хочете використовувати в майбутньому іншу СУБД? Якщо так, то не використовується для спеціальних SQL-матеріалів поточної СУБД. Видаліть логіку у вашій програмі.

Не використовує:

• пробіли в назвах таблиць та назви стовпців
• Символи, що не належать Ascii, у назвах таблиць та стовпців
• прив’язка до конкретного нижнього або верхнього регістру. І ніколи не використовуйте 2 таблиці чи стовпці, які відрізняються лише нижньою та великою літерами.
• не використовує ключові слова SQL для назв таблиць або стовпців, таких як "ВІД", "МЕЖДУ", "ВИДАЛИТИ" тощо

рекомендації:

• Використовуйте NVARCHAR або його еквіваленти для підтримки unicode, тоді у вас немає проблем із кодовими сторінками.
• Дайте кожному стовпцю унікальну назву. Це полегшує процес приєднання, щоб вибрати стовпець. Дуже складно, якщо в кожній таблиці є стовпець "Ідентифікатор" або "Ім'я" або "Опис". Використовуйте XyzID та AbcID.
• Використовуйте пакет ресурсів або дорівнює для складних виразів SQL. Це полегшує перехід на іншу СУБД.
• Не вкладає жодних типів даних. Інша СУБД не може мати цей тип даних. ДЛЯ ПРИКЛАДУ Oracle Daes не має МАЛЬКОГО лише числа.

Я сподіваюся, що це хороша відправна точка.

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

Залежить від того, що ви маєте на увазі під шаблоном. Якщо ви думаєте про особу / компанію / транзакцію / продукт та інше, то так - існує багато загальних схем баз даних.

Якщо ви думаєте про Factory, Singleton ... тоді ні - вам це не потрібно, оскільки вони занадто низькі для програмування БД.

Якщо ви думаєте, як називати об'єкти бази даних, то це під категорією умовних умов, а не дизайн сам по собі.

BTW, S.Lott, відносини «один до багатьох» і «багато-до-багатьох» не є «зразками». Вони є основними складовими реляційної моделі.