Wzorce baz danych [duplikat]

To pytanie ma już odpowiedź tutaj:

Czy ktoś wie o gazetach/książkach / itp. te wzory dokumentów dla baz danych? Na przykład, jedną z powszechnych reguł jest to, że każda tabela powinna mieć klucz podstawowy i że klucz powinien być pozbawiony treści informacyjnej . Więc byłem zastanawiasz się, czy ktoś napisał książkę lub opublikował prace dotyczące wzorców projektowych do projektowania relacyjnych baz danych?

@Gajusz,

To jest pytanie, które projektant baz danych musi zważyć-jaka jest prawdopodobna stabilność struktury bazy danych? Biorąc pod uwagę wystarczająco długi horyzont, nic nie jest stabilne. Albo powiedzieć converse, biorąc pod uwagę wystarczająco długi horyzont, wszystko może ulec zmianie. Klucz zastępczy (teoretycznie) nigdy nie powinien zmieniać swojego znaczenia, ponieważ nigdy nie miał to znaczy na początek.

Myślę, że inną rzeczą do rozważenia w tym konkretnym scenariuszu projektu jest to, kto będzie widział klucz główny? Jeśli klucz podstawowy jest czymś, do czego użytkownicy końcowi będą musieli się odwoływać, sensowne jest uczynienie go czymś, co mogą zrozumieć. Ale nie mogę wymyślić wielu przypadków, w których użytkownik końcowy musi zobaczyć klucz podstawowy; zazwyczaj klucz podstawowy jest obecny, aby umożliwić silnikowi DB przyspieszenie pewnych operacji.

Moja oryginalna myśl zadając pytanie, było znalezienie wzorców projektowych dla projektowania baz danych, które zostały skodyfikowane przez bardziej doświadczonych projektantów baz danych niż ja, aby, miejmy nadzieję, uniknąć pewnych łatwych do uniknięcia błędów. Byłoby ciekawie przeczytać, gdyby ktoś kiedykolwiek skodyfikował projekt bazy danych anty-patterns.

Author: casperOne, 2008-09-04
Source

6 answers

W szczególności, jeśli chodzi o klucze: zdecydowanie nie zgadzam się z dziwnym pomysłem, że klucze muszą być bez znaczenia. Ogólnie uważam bazę danych za zbiór faktów; jak tylko zaczniesz dodawać dowolne liczby (jak wygenerowane klucze) i inne nieistotne informacje do niej, powinien to być znak ostrzegawczy. Polecam Ten artykuł Joe Celko , aby uzyskać więcej informacji na temat kluczy.

Uwagi ogólne:

Propozycje projektów schematów / modeli danych dla różnych firm: David C. Hay: wzorce modeli danych: konwencje myśli Raczej stare, ale nie bez powodu jest jeszcze w druku
http://www.dorsethouse.com/books/dmp.html

Może niezbyt wzorowy, ale i tak bardzo dobry: Stéphane Faroult, Peter Robson: Sztuka SQL http://oreilly.com/catalog/9780596008949/

Kolejny, który mogę polecić: Vadim Tropashko: SQL Design Patterns - the Expert Guide to SQL Programowanie http://www.rampant-books.com/book_2006_1_sql_coding_styles.htm

Systematic text-książka o modelowaniu danych: Graeme Simsion & Graham Witt, " Podstawy Modelowania Danych" http://www.elsevierdirect.com/product.jsp?isbn=9780126445510

Może rzeczywiście szukasz "poradnika stylu"?. I ta sprawa: Joe Celko: styl programowania SQL http://www.elsevierdirect.com/product.jsp?isbn=9780120887972

 10
Author: Troels Arvin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-04 18:57:44

Książki E. F. Codda i C. J. Date są najbardziej oczywistymi odpowiedziami. Nie czytałem tej konkretnej książki, ale znam autorów, prawdopodobnie jest całkiem dobra.

Matematyka stosowana dla specjalistów od baz danych Przez Lexxa de Haana i Toona Koppelaarsa.

 4
Author: Ethan Post,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-04 17:55:17

Właściwie, myślę, że zasadą jest zwykle użycie naturalnego klucza, a nie zastępczej, gdy tylko jest to możliwe...

Więc jeśli mam, na przykład, tabelę faktur i tabelę InvoiceDetail, prawdopodobnie możemy użyć InvoiceNumber jako naszego klucza podstawowego na pierwszym. Już istnieje w naszych danych i (zakładam?) byłby wyjątkowy. W przypadku drugiej tabeli prawdopodobnie utkniemy z potrzebą klucza zastępczego-niezależnie od tego, czy jest on połączony z numerem faktury jako złożony, czy nie.

W każdym razie, wracając do pierwotnego pytania... link hometoast powinien ci pomóc.

-- Kevin Fairchild

 3
Author: Kevin Fairchild,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-04 17:59:51

Aby odpowiedzieć dokładnie: tak . Jest mnóstwo informacji napisanych na "dobrym" projekcie bazy danych. Chociaż twoja przykładowa zasada jest z pewnością wątpliwa.

 2
Author: hometoast,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-04 17:50:40

SQL Anti-Patterns Bill Karwin jest bardzo łatwy do odczytania (nie suchy) i wyjaśnia w dość jasny sposób wiele różnych potencjalnych pułapek, jak możesz ich używać i jak/dlaczego robić rzeczy dobrze.

 2
Author: memilanuk,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-30 14:06:03

Używanie kluczy podstawowych o znaczeniu biznesowym ("klucze naturalne") z pewnością ma swoje zalety, ale może utrudnić refaktoryzację bazy danych Bardzo. Zachowaj ostrożność, zwłaszcza jeśli istnieje jakikolwiek powód, aby sądzić, że struktura bazy danych zmieni się w czasie.

 1
Author: James A. Rosen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-04 18:22:02