Wzorce Projektowania Relacyjnych Baz Danych?

Oto link do Pana, który opracował kilkaset darmowych schematów baz danych.

Http://www.databaseanswers.org/data_models/

Być może, jeśli musisz szybko zbudować db, to da ci punkt wyjścia pod względem tabel i relacji w danym schemacie. Pamiętaj, że prawdopodobnie będziesz musiał zmodyfikować ten punkt początkowy. Uważam, że jest to bardzo przydatne.

Po drugie magazyn SQL Server ma okazjonalną kolumnę o nazwie " Modeler danych" który jest bardzo edukacyjny i często zawiera kompletne schematy dla danego systemu.

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

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

Wzór nie jest trywialnie wielokrotnego użytku. Możesz jednak wdrożyć swój projekt w dół zgodnie ze wzorem.

Wzorce projektowania relacyjnego obejmują takie rzeczy jak:

1. Relacje jeden do wielu (master-detail, rodzic-dziecko) relacje za pomocą obcego klucz.

2. Wiele do wielu relacji ze stołem mostowym.

3. Opcjonalne relacje jeden do jednego zarządzane z Null w kolumnie FK.

4. Gwiazda-schemat: wymiar i fakt, projekt OLAP.

5. W pełni znormalizowany projekt OLTP.

6. Wiele zindeksowanych kolumn wyszukiwania w wymiarze.

7. "tabela wyszukiwania" zawierająca PK, opis i wartości kodu używane przez jedną lub więcej aplikacji. Po co mieć kod? I 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; jest to wzór, czasami jest zły, czasami jest dobry.] Jest to Tabela z dużą ilością wstępnie połączonych rzeczy, które naruszają drugą i trzecią normalną formę.

9. Tablica. Jest to tabela, która narusza pierwszą normalną formę poprzez umieszczenie tablicy lub sekwencji wartości w kolumnach.

10. Baza danych mieszanych. To jest baza danych znormalizowany do przetwarzania transakcji, ale z wieloma dodatkowymi indeksami do raportowania i analizy. Nie rób tego . Ludzie i tak to robią, więc to nadal wzór.

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

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

Zobacz ten blog- programista baz danych .

Opisuje niektóre wzorce baz danych .

Książki Joe Celko są doskonałe do tego rodzaju rzeczy, w szczególności "SQL dla Smarties". Ma kilka innowacyjnych rozwiązań typowych problemów, z których większość to wzorce projektowe wielokrotnego użytku.

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

AskTom jest prawdopodobnie najbardziej pomocnym źródłem informacji na temat najlepszych praktyk w Oracle DBs. (Zwykle po prostu wpisuję "asktom" jako pierwsze słowo zapytania google na konkretny temat)

Myślę, że nie wypada mówić o wzorcach projektowych z relacyjnymi bazami danych. Relacyjne bazy danych są już zastosowaniem "wzorca projektowego" do problemu (problemem jest "jak reprezentować, przechowywać i pracować z danymi przy zachowaniu ich integralności" , a projekt jest model relacyjny). Inne podejścia (ogólnie uznane za przestarzałe) to modele nawigacyjne i hierarchiczne (i jestem nure wiele innych istnieje).

Mówiąc o tym, można rozważyć "Hurtownia danych" jako nieco oddzielny "wzór" lub podejście w projektowaniu baz danych. W szczególności możesz być zainteresowany przeczytaniem schematu Gwiazdy .

Po wielu latach rozwoju bazy danych mogę powiedzieć, że jest kilka pytań, na które powinieneś odpowiedzieć zanim zaczniesz:

Pytania:

• czy chcesz użyć w przyszłości innego DBMS? If yes then nie używa do specjalnych danych SQL z bieżącego DBMS. Usuń logikę w aplikacji.

Nie używa:

• białe spacje w nazwach tabel i kolumn
• znaki spoza Ascii w tabeli i kolumnie nazwy
• wiązanie z konkretnymi małymi lub dużymi literami. 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 masz problemów ze stronami kodowymi.
• nadaj każdej kolumnie unikalną nazwę. Dzięki temu łatwiej jest wybrać kolumnę przy połączeniu. On bardzo trudne, jeśli każda tabela ma kolumnę " ID " lub "nazwa" lub "opis". Stosować XyzID i AbcID.
• użyj pakietu zasobów lub równych dla złożonych wyrażeń SQL. Łatwiej jest przełączyć się na inny DBMS.
• nie rzuca mocno na żaden typ danych. Inny DBMS nie może mieć tego typu danych. Na przykład dae Oracle nie ma MALEJINT tylko liczba.

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

Twoje pytanie jest trochę niejasne, ale przypuszczam, że UPSERT można uznać za wzorzec projektowy. Dla języków, które nie implementują MERGE, istnieje wiele alternatyw do rozwiązania problemu (jeśli istnieje odpowiedni wiersz, UPDATE; else INSERT).

Zależy co masz na myśli przez wzorzec. Jeśli myślisz osoba / firma / transakcja / produkt i takie, to tak - istnieje wiele ogólnych schematów bazy danych już dostępne.

Jeśli myślisz o fabryce, Singleton... w takim razie nie-nie potrzebujesz żadnego z nich, ponieważ są zbyt niskie na programowanie DB.

Jeśli myślisz o nazwach obiektów bazodanowych, to jest to kategoria Konwencji, a nie design per se.

BTW, S. Lott, one-to-many and many-to-many związki nie są "wzorcami". Są podstawowym budulcem modelu relacyjnego.

Ta książka wygląda ciekawie

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