Co jest specjalnego w kluczu podstawowym?
Jaki jest cel tabeli w schemacie? Jaki jest cel klucza stołu? Co jest specjalnego w kluczu podstawowym? Dyskusje na temat kluczy podstawowych wydają się nie uwzględniać tego, że klucz podstawowy jest częścią tabeli, a ta tabela jest częścią schematu. To, co jest najlepsze dla tabeli i relacji między tabelami, powinno kierować używanym kluczem.
Tabele (i relacje między tabelami) zawierają fakty dotyczące informacji, które chcesz zapisać. Fakty te powinny być niezależne, znaczące, łatwe do zrozumienia i niesprzeczne. Z perspektywy projektowania inne tabele dodane lub usunięte ze schematu nie powinny wpływać na tabelę. Musi istnieć cel przechowywania danych związanych tylko z samą informacją. Zrozumienie tego, co jest przechowywane w tabeli, nie powinno wymagać poddania się projektowi badań naukowych. Żaden fakt przechowywany w tym samym celu nie powinien być przechowywany więcej niż jeden raz. Klucze to całość lub część zapisywanych informacji, która jest unikalna, a klucz podstawowy to specjalnie wyznaczony klucz, który ma być głównym punktem dostępu do tabeli (tzn. Powinien zostać wybrany ze względu na spójność i wykorzystanie danych, a nie tylko wstawianie występ).
- NA BOK: Niestety efektem ubocznym większości baz danych projektowanych i rozwijanych przez programistów aplikacji (którym czasami jestem) jest to, że to, co najlepsze dla aplikacji lub frameworka aplikacji, często decyduje o wyborze klucza podstawowego dla tabel. Prowadzi to do liczb całkowitych i kluczy GUID (ponieważ są one łatwe w użyciu w ramach aplikacji) i monolitycznych projektów tabel (ponieważ zmniejszają one liczbę obiektów struktury aplikacji potrzebnych do reprezentowania danych w pamięci). Te decyzje projektowe baz danych oparte na aplikacjach prowadzą do poważnych problemów z spójnością danych, gdy są stosowane w skali. Ramy aplikacji zaprojektowane w ten sposób w naturalny sposób prowadzą do tworzenia tabel na raz. „Częściowe rekordy” są tworzone w tabelach i danych wypełnianych w miarę upływu czasu. Unika się interakcji z wieloma tabelami lub gdy użycie powoduje niespójne dane, gdy aplikacja działa nieprawidłowo. Te projekty prowadzą do danych, które nie mają znaczenia (lub są trudne do zrozumienia), danych rozłożonych na tabele (musisz spojrzeć na inne tabele, aby zrozumieć aktualną tabelę) i zduplikowanych danych.
Mówiono, że klucze podstawowe powinny być tak małe, jak to konieczne. Powiedziałbym, że klucze powinny być tak duże, jak to konieczne. Należy unikać losowego dodawania nieistotnych pól do tabeli. Jeszcze gorzej jest zrobić klucz z losowo dodanego, pozbawionego znaczenia pola, szczególnie gdy niszczy zależność łączenia z innej tabeli do klucza innego niż podstawowy. Jest to uzasadnione tylko wtedy, gdy nie ma dobrych kluczy kandydujących w tabeli, ale to z pewnością jest oznaką złego projektu schematu, jeśli jest stosowane we wszystkich tabelach.
Mówiono również, że klucze podstawowe nigdy nie powinny się zmieniać, ponieważ aktualizacja klucza podstawowego zawsze powinna być wykluczona. Ale aktualizacja jest taka sama jak usuwanie, a następnie wstawianie. Zgodnie z tą logiką nigdy nie należy usuwać rekordu z tabeli za pomocą jednego klucza, a następnie dodawać kolejny rekord za pomocą drugiego klucza. Dodanie zastępczego klucza podstawowego nie usuwa faktu, że istnieje inny klucz w tabeli. Aktualizacja klucza innego niż podstawowy tabeli może zniszczyć znaczenie danych, jeśli inne tabele mają zależność od tego znaczenia za pomocą klucza zastępczego (np. Tabela statusu z kluczem zastępczym, którego opis statusu został zmieniony z „Przetworzone” na „Anulowane” „zdecydowanie uszkodziłoby dane). To, co zawsze powinno być wykluczone, to niszczenie znaczenia danych.
Powiedziawszy to, jestem wdzięczny za wiele źle zaprojektowanych baz danych, które istnieją w dzisiejszych firmach (behemoty pozbawione znaczenia-zastępcze-dane-uszkodzone-1NF), ponieważ oznacza to, że ludzie, którzy rozumieją odpowiedni projekt bazy danych, mają nieskończoną ilość pracy. . Ale ze smutnej strony, czasami sprawia, że czuję się jak Syzyf, ale założę się, że miał jeden 401k (przed katastrofą). Trzymaj się z dala od blogów i stron internetowych w przypadku ważnych pytań dotyczących projektowania baz danych. Jeśli projektujesz bazy danych, wyszukaj Data CJ. Możesz także odwoływać się do Celko dla SQL Server, ale tylko jeśli najpierw trzymasz nos. Po stronie Oracle odwołaj się do Tom Kyte.