Dlaczego klucz powinien być wyraźny?

15

Jestem bardzo nowy w temacie baz danych, więc może to zabrzmieć nieświadomie, ale jestem ciekawy, dlaczego klucz powinien być wyraźnie określony w tabeli. Czy to przede wszystkim po to, aby powiedzieć użytkownikowi, że podana wartość kolumny ma (miejmy nadzieję) niepowtarzalność w każdym wierszu? Ta wyjątkowość powinna nadal istnieć, nawet jeśli nie jest wspomniana.

primary-key unique-constraint

— dsaxton
źródło

Czy masz na myśli to, że jeśli posiadasz UNIKALNY klucz, po co zawracać sobie głowę posiadaniem klucza podstawowego?

— Vérace,

1

Dlaczego w ogóle są zadeklarowane? Wydaje się to bardzo pomocne, ale czy w rzeczywistości konieczne jest posiadanie działającej bazy danych?

— dsaxton,

1

Nie są one potrzebne do działania bazy danych, ale są potrzebne do tego, aby dane „działały”, tj. Były spójne, ponieważ dokładnie tak nakazujesz serwerowi bazy danych zachować spójność informacji.

— Andriy M

Jeśli baza danych wie, że dane pole jest kluczem, efektem ubocznym jest to, że może pomóc w zlokalizowaniu wiersza zawierającego klucz znacznie szybciej niż w przypadku konieczności przeglądania wszystkich wierszy w tabelach. Indeksy są bardzo ważną częścią tego, dlaczego bazy danych są przydatne.

— Thorbjørn Ravn Andersen

32

Oczywiście sugerujesz, że aplikacje CONSTRAINTw bazie danych powinny być egzekwowane przez aplikacje, które / który uzyskują dostęp do tej bazy danych?

Istnieje wiele powodów, dla których jest to zły (zły, zły ...) pomysł.

1) Jeśli budujesz silnik typu „roll-your-own” z ograniczeniem (tj. W kodzie aplikacji), to emulujesz tylko to, co wydały Oracle / SQL Server / MySQL / PostgreSQL / <. Ktokolwiek ...> lata pisania. Ich kod CONSTRAINT był przez te lata testowany przez dosłownie miliony użytkowników końcowych.

2) Z całym szacunkiem dla Ciebie i Twojego zespołu, nie zamierzamy zrobić to dobrze nawet w ciągu kilku lat - od tutaj , MySQL kod sam koszt 40 milionów dolarów. A MySQL jest najtańszym z 3 serwerów powyżej i nawet nie implementują KONTRAKTÓW KONTROLNYCH. Oczywiście uzyskanie pełnej poprawności RI (Referential Integrity) jest trudne.

Często odwiedzałem fora Oracle i nie mogę powiedzieć, ile razy jakiś biedny menedżer / programista rzucił na niego projekt, w którym geniusz, który miał swoją pracę, wpadł na „błyskotliwy” pomysł robienia tego, co sugerujesz .

Jonathan Lewis (napisał 550-stronicową książkę na temat podstaw optymalizatora Oracle ) podaje jako nie. 2 z jego Design Disasters w innej książce („ Tales of the Oak Table ” - The Oak Table to grupa ekspertów Oracle) to

Sprawdzimy integralność danych na poziomie aplikacji, zamiast wykorzystywać możliwości sprawdzania ograniczeń Oracle.

3) Nawet jeśli jakimś cudem potrafisz poprawnie wdrożyć RI, będziesz musiał całkowicie go ponownie wdrożyć dla każdej aplikacji, która dotyka tej bazy danych - a jeśli twoje dane są ważne, nowe aplikacje tak. Wybór tego paradygmatu doprowadzi ciebie i twoich kolegów programistów (nie wspominając o personelu pomocniczym i sprzedaży) do życia w ciągłej walce z ogniem i nędzy.

Możesz przeczytać więcej o tym, dlaczego wdrażanie OGRANICZEŃ danych na poziomie aplikacji jest szaleństwem tutaj , tutaj i tutaj .

Aby szczegółowo odpowiedzieć na twoje pytanie:

Dlaczego w ogóle są zadeklarowane? Wydaje się to bardzo pomocne, ale czy w rzeczywistości konieczne jest posiadanie działającej bazy danych

Dlatego, że KEYs (albo PRIMARY, FOREIGN, UNIQUEczy tylko zwykłe INDEXES) są uznane jest, że choć to nie jest to bezwzględnie konieczne do bazy danych, aby je za to działać, to jest absolutnie niezbędne dla nich zostać uznane za nim funkcjonować dobrze .

— Vérace
źródło

1

Dziękuję za odpowiedź. Prawdopodobnie będę musiał dowiedzieć się więcej, aby w pełni to zrozumieć. (Właściwie to nie należę do zespołu, po prostu uczę się o bazach danych z ciekawości.)

— dsaxton

2

Przeczytaj kilka książek (Data, Garcia-Molina ...) i wróć do nas, jeśli masz konkretne pytania (pytania, które są zbyt ogólne, są tutaj uważane za nie na temat). ps Witaj na forum :-)

— Vérace

Chociaż nigdy, przenigdy nie sugerowałbym, aby nie wprowadzać żadnych ograniczeń w bazie danych (zawsze powinieneś mieć klucz podstawowy i klucze obce na minimalnym poziomie), możesz uniknąć nr 3, ponieważ wszystkie aplikacje korzystają z usługi wspólnej (architektura zorientowana na usługi ). (Prawdopodobnie jest to coś, co należy wziąć pod uwagę dla wielu konsumentów, ponieważ wykonywanie każdej ostatniej kontroli integralności, której potrzebujesz w bazie danych, może być również koszmarne. Pomyśl, że wyzwalacze wszędzie sprawdzają się w tabelach i wierszach przez cały czas.)

— jpmc26,

10

Podczas tworzenia klucza w bazie danych silnik DBMS wymusza ograniczenie unikatowości kluczowych atrybutów. Służy to co najmniej trzem powiązanym celom:

Integralność danych: duplikatów danych nie można wprowadzić do kluczowych atrybutów. Wszelkie zależności od kluczy są zatem gwarantowane.
Identyfikacja: użytkownicy mogą polegać na kluczach w celu dokładnej identyfikacji i aktualizacji danych.
Optymalizacja: informacje (metadane), które atrybuty są unikalne, są dostępne dla optymalizatora zapytań DBMS. Informacje te umożliwiają optymalizatorowi uproszczenie wykonywania zapytań w określony sposób, dzięki czemu zapytania będą wykonywane szybciej.

— nvogel
źródło

8

Dodam jeden aspekt do istniejących doskonałych odpowiedzi: Dokumentację. Często ważne jest, aby zobaczyć, jakiego rodzaju kluczy możesz użyć do identyfikacji bytu. Każda kombinacja unikalnych kolumn jest kluczem kandydującym.

Klucz podstawowy wydaje się być szczególnie przydatną koncepcją w praktyce.

Niezależnie od tego, czy egzekwujesz klucz, czy nie (prawdopodobnie powinieneś) dokumentacja jest cenna sama w sobie.

— boot4life
źródło

1

Diagramy baz danych! Pierwszą rzeczą, którą zawsze robię, gdy poproszę o powiedzenie czegoś znaczącego o oprogramowaniu, którego nie znam, jest sprawdzenie, czy używa relacyjnej bazy danych, a jeśli tak, spróbuj utworzyć diagram bazy danych. To da mi doskonały obraz informacji, z którymi współpracuje aplikacja. Niestety 90% baz danych, które widziałem, nie deklaruje kluczy obcych, więc diagramy są tylko zestawami tabel. Zmniejszenie niejawnych kluczy obcych na poziomie aplikacji wymaga zgadywania i poprawiania.

— reinierpost

1

@reinierpost W pełni się zgadzam. Dane są najcenniejszym obiektem do dokumentowania i utrzymywania czystości, ponieważ są przechowywane na zawsze. Kod może się zmienić; jest bardziej przejściowy.

— boot4life

@reinierpost - skonsultowano się z firmą, która dostarczyła oprogramowanie dla całej infrastruktury kolejowej dużego kraju europejskiego (duża - pomyśl miliardy widżetów) i powiedziałem: „Hum, po prostu uruchomię zapytanie, aby sprawdzić FOREIGN KEYdefinicje, aby uzyskać wyczuć system ”. Moje zapytanie zwróciło zip !!! Jasne, że mój SQL musiał się mylić, wspomniałem o tym jednemu ze starszych programistów. Z dumą (nie mniej) oznajmił (jakby przedstawiał nowonarodzonego syna), że system nie ma żadnych FK, ponieważ „wszystkie wyszukiwania są na PRIMARY KEYs” - (nieistotne). <Doh ...> a la Homer Simpson!

— Vérace

5

Kolejny powód, dla którego należy używać OGRANICZEŃ zamiast niektórych wewnętrznych kodów aplikacji:

Co się stanie, jeśli programista / dba użyje instrukcji insert / update / delete do modyfikacji danych bezpośrednio w bazie danych? W takim przypadku cała twoja ładna integralność referencyjna oparta na aplikacji będzie bezużyteczna. Wiem, niektórzy deweloperzy lubią możliwość bezpośredniej modyfikacji danych bez konieczności zawracania sobie głowy RI, ponieważ wiedzą, co robią - przynajmniej przez większość czasu (ale nie zawsze)

PS: Oczywiście możesz tworzyć wyzwalacze, ale zwykle są one strasznie wolne (w porównaniu do KONSTRUKCJI).

— Thomas Franz
źródło