Wzorce projektowania relacyjnych baz danych? [Zamknięte]

Wzory projektowe są zwykle związane z projektowaniem obiektowym.
Czy istnieją wzorce projektowe do tworzenia i programowania relacyjnych baz danych ?
Wiele problemów z pewnością musi mieć rozwiązania wielokrotnego użytku.

Przykłady obejmują wzorce do projektowania tabel, procedur przechowywanych, wyzwalaczy itp.

Czy istnieje internetowe repozytorium takich wzorców, podobne do martinfowler.com ?

Przykłady problemów, które mogą rozwiązać wzorce:

• Przechowywanie danych hierarchicznych (np. Pojedyncza tabela typu i wiele tabel z kluczem 1: 1 i różnicami ...)
• Przechowywanie danych o zmiennej strukturze (np. Kolumny ogólne vs xml vs kolumna rozdzielana ...)
• Denormalizuj dane (jak to zrobić przy minimalnym wpływie itp.)

W serii podpisów Martina Fowlera jest książka o nazwie Refaktoryzacja baz danych . Zawiera listę technik refaktoryzacji baz danych. Nie mogę powiedzieć, że tyle słyszałem listę wzorców baz danych.

Gorąco poleciłbym również wzorce modelu danych Davida C. Haya oraz kontynuację mapy metadanych, która opiera się na pierwszej i jest o wiele bardziej ambitna i intrygująca. Przedmowa sama w sobie jest oświecająca.

Świetnym miejscem do poszukiwania niektórych wstępnie konserwowanych modeli baz danych jest także seria danych Len Lenstona, seria danych 1, zawiera uniwersalne modele danych (pracownicy, konta, wysyłka, zakupy itp.). Tom 2 zawiera modele danych specyficzne dla branży (księgowość, opieka zdrowotna itp.), tom 3 zawiera wzorce modeli danych.

Wreszcie, chociaż ta książka pozornie dotyczy UML i modelowania obiektów, Modelowanie Petera Coada w kolorze z UML zapewnia proces modelowania jednostek oparty na „archetypach”, wychodząc z założenia, że ​​istnieją 4 podstawowe archetypy dowolnego modelu obiektów / danych

Wzory projektowe nie są trywialnymi rozwiązaniami wielokrotnego użytku.

Wzory projektowe są z definicji wielokrotnego użytku. Są to wzorce, które można wykryć w innych dobrych rozwiązaniach.

Wzór nie nadaje się do wielokrotnego użytku. Możesz jednak zaimplementować swój projekt puchowy zgodnie ze wzorem.

Wzorce projektowania relacyjnego obejmują między innymi:

1. Relacje jeden do wielu (główny-detal, rodzic-dziecko) za pomocą klucza obcego.

2. Relacje wiele do wielu z tabelą pomostową.

3. Opcjonalne relacje jeden do jednego zarządzane za pomocą NULL w kolumnie FK.

4. Star-Schema: Dimension and Fact, OLAP design.

5. W pełni znormalizowany projekt OLTP.

6. Wiele indeksowanych kolumn wyszukiwania w wymiarze.

7. „Tabela odnośników”, która zawiera PK, opis i wartości kodowe wykorzystywane przez jedną lub więcej aplikacji. Dlaczego warto mieć kod? Nie wiem, ale kiedy trzeba ich użyć, jest to sposób na zarządzanie kodami.

8. Uni-table. [Niektórzy nazywają to anty-wzorem; to wzór, czasem zły, czasem dobry.] To jest stół z dużą ilością wstępnie połączonych rzeczy, które naruszają drugą i trzecią normalną formę.

9. Tabela tablic. Jest to tabela, która narusza pierwszą normalną formę, mając tablicę lub sekwencję wartości w kolumnach.

10. Baza danych o mieszanym zastosowaniu. Jest to baza danych znormalizowana do przetwarzania transakcji, ale z wieloma dodatkowymi indeksami do raportowania i analiz. To jest anty-wzór - nie rób tego. Ludzie i tak to robią, więc to wciąż wzór.

Większość ludzi, którzy projektują bazy danych, może łatwo wyrzucić pół tuzina „To kolejny z nich”; są to wzorce projektowe, których używają regularnie.

Nie obejmuje to administracyjnych i operacyjnych wzorców użytkowania i zarządzania.

AskTom jest prawdopodobnie najbardziej pomocnym źródłem najlepszych praktyk dotyczących baz danych Oracle. (Zazwyczaj po prostu wpisuję „asktom” jako pierwsze słowo zapytania Google na określony temat)

Nie sądzę, że naprawdę właściwe jest mówienie o wzorcach projektowych w relacyjnych bazach danych. Relacyjne bazy danych już stosują „wzorzec projektowy” do problemu (problemem jest „jak reprezentować, przechowywać i pracować z danymi przy zachowaniu ich integralności”, a projekt jest modelem relacyjnym). Innymi aplikacjami (ogólnie uważanymi za przestarzałe) są modele nawigacyjne i hierarchiczne (i jestem pewien, że istnieje wiele innych).

Powiedziawszy to, możesz rozważyć „hurtownię danych” jako nieco odrębny „wzorzec” lub podejście do projektowania baz danych. W szczególności możesz być zainteresowany czytaniem o schemacie Star .

Po wielu latach rozwoju bazy danych mogę powiedzieć, że nie ma żadnych przejść i kilka pytań, na które należy odpowiedzieć przed rozpoczęciem:

pytania:

• Czy chcesz w przyszłości użyć innego DBMS? Jeśli tak, to nie używa specjalnych elementów SQL bieżącego DBMS. Usuń logikę z aplikacji.

Nie używa:

• białe spacje w nazwach tabel i nazw kolumn
• Znaki inne niż ascii w nazwach tabel i kolumn
• wiązanie do określonej małej lub dużej litery. I nigdy nie używaj 2 tabel lub kolumn, które różnią się tylko małymi i dużymi literami.
• nie używa słów kluczowych SQL do nazw tabel lub kolumn, takich jak „FROM”, „BETWEEN”, „DELETE” itp.

rekomendacje:

• Użyj NVARCHAR lub odpowiedników do obsługi Unicode, wtedy nie będziesz mieć problemów ze stronami kodowymi.
• Nadaj każdej kolumnie unikalną nazwę. Ułatwia to łączenie w celu wybrania kolumny. Jest to bardzo trudne, jeśli każda tabela ma kolumnę „ID” lub „Nazwa” lub „Opis”. Użyj XyzID i AbcID.
• Użyj pakietu zasobów lub równości dla złożonych wyrażeń SQL. Ułatwia przejście do innego DBMS.
• Nie rzuca mocno na żaden typ danych. Inny DBMS nie może mieć tego typu danych. Dla przykładu Daes Oracle nie mają SMALLINT tylko liczby.

Mam nadzieję, że to dobry punkt wyjścia.

Twoje pytanie jest nieco niejasne, ale przypuszczam, że UPSERTmożna je uznać za wzór projektowy. W przypadku języków, które nie wdrażają MERGE, szereg alternatywnych rozwiązań, aby rozwiązać ten problem (jeżeli odpowiednie wiersze istnieje UPDATE, w przeciwnym razie INSERT) występują.

Zależy, co rozumiesz przez wzorzec. Jeśli myślisz Osoba / Firma / Transakcja / Produkt i tak, to tak - istnieje już wiele ogólnych schematów baz danych.

Jeśli myślisz o Factory, Singleton ... to nie - nie potrzebujesz żadnego z nich, ponieważ są one zbyt niskie do programowania DB.

Jeśli myślisz o nazewnictwie obiektów bazy danych, to należy do kategorii konwencji, a nie projektu jako takiego.

BTW, S.Lott, relacje jeden do wielu i wiele do wielu nie są „wzorami”. Są to podstawowe elementy składowe modelu relacyjnego.