Dlaczego klucze podstawowe mają własne nazwy?

Z matematycznego punktu widzenia, zakładając, że tabela ma co najwyżej jeden klucz podstawowy, wydaje się, że krótkowzroczna decyzja projektowa odnosi się do kluczy podstawowych o dowolnej dowolnej nazwie zamiast prostej właściwości tabeli.

W konsekwencji, aby zmienić klucz podstawowy z nieklastrowego na klastrowy lub odwrotnie, musisz najpierw wyszukać jego nazwę, a następnie upuścić ją i w końcu przeczytać.

Czy jest jakaś korzyść z używania dowolnych nazw, których nie widzę, czy też DBMS nie używa dowolnych nazw dla kluczy podstawowych?

Edytuj 22.02.2011 (22.02.2011 dla tych, którzy nie chcą sortować tam daty):

Pozwól, że pokażę funkcję, za pomocą której możesz uzyskać nazwy klucza podstawowego z jego nazw tabel (używając wczesnych tabel systemowych sybase, zwanych też sql-sever):

create function dbo.get_pk (@tablename sysname)
returns sysname
as
begin
    return (select k.name
    from sysobjects o 
        join sysobjects k   on k.parent_obj = o.id 
    where o.name = @tablename
    and o.type = 'U'
    and k.type = 'k')
end
go

Jak głosi gbn, nikt tak naprawdę nie lubi wygenerowanej nazwy, jeśli nie podasz wyraźnej nazwy:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

Właśnie dostałem

PK__example___3213E83F527E2E1D

Ale dlaczego nazwy w obiektach systemowych muszą być unikalne. Byłoby całkowicie OK, aby użyć dokładnie tej samej nazwy dla tabeli i jej klucza podstawowego.

W ten sposób nie musieliśmy konfigurować konwencji nazewnictwa, które mogłyby zostać przypadkowo naruszone.

Teraz odpowiedzi dla Mariana:

1. Użyłem tylko zadania zmiany klastra w nieklastrowany klucz podstawowy jako przykład, w którym muszę znać rzeczywistą nazwę pk, aby móc go upuścić.
2. Rzeczy nie muszą mieć odpowiednich nazw, wystarczy, że można je łatwo jednoznacznie opisać. To jest podstawa abstrakcji. Programowanie obiektowe idzie w tym kierunku. Nie musisz używać różnych nazw dla podobnych właściwości różnych klas.
3. Jest to arbitralne, ponieważ jest własnością tabeli. Nazwa tabeli jest wszystkim, co musisz wiedzieć, jeśli chcesz z niej korzystać.

Klucze podstawowe (i inne unikalne ograniczenia) są implementowane jako indeksy i są traktowane dokładnie w ten sam sposób - z punktu widzenia programisty nie ma sensu, aby mieć oddzielne ścieżki kodu dla PK i indeksów (podwoiłoby to potencjał błędów).

Poza tym, do którego odwołują się klucze obce, PK jest tylko unikalnym ograniczeniem, które z kolei jest implementowane jako indeks, więc zmiana właściwości PK jest taka sama jak zmiana właściwości dowolnego innego indeksu. Posiadanie także wyraźnej nazwy oznacza, że ​​można się do nich odwoływać w podpowiedziach do zapytań, jak w każdym innym indeksie.

Nie jestem pewien, czy w pełni rozumiem pytanie.

Jeśli miałeś indeks na stole i chciałeś / potrzebowałeś zmienić indeks, czy nie musiałbyś również zmieniać go zgodnie z jego nazwą? Podejrzewam, że możesz sprawdzić identyfikator obiektu dla indeksu i wykonać aktualizację w ten sposób, ale nazwy pomagają ludziom logicznie zrozumieć, z jakim obiektem pracują.

Być może więc odpowiedź brzmi: jeśli masz silną konwencję nazewnictwa (tj. Nazwa_PK dla klucza głównego), to będziesz w stanie łatwo zidentyfikować, że pracujesz z kluczem podstawowym tabeli.

Przypuszczam, że to samo można powiedzieć o definiowaniu relacji FK. Myślę, że nazwy są używane do interpretacji logicznej, ponieważ same obiekty mają różne ID obiektów.

Powiedziałbym, że jest to szczegół implementacji dla czytelności człowieka.

Nazwy ograniczające są opcjonalne (w SQL Server co najmniej), ale chciałbym mieć PK_MyTablena MyTablezamiastPK_MyTabl___16feb6d8a

Historycznie, klucze podstawowe i klucze unikatowe są nazywane kluczami kandydującymi, jak uczy Christopher J. Date.

Klucz kandydacki to indeks, który jest unikalny i może odtwarzać rzut klucza podstawowego. Zatem wszystkie klucze kandydujące są unikatowymi kluczami. Klucz podstawowy to po prostu oznaczenie jednego z kluczy kandydujących jako preferowanego sposobu dostępu do danych tabeli.

W świetle tego nazwa PRIMARY KEY to dowolna nazwa preferowanego klucza kandydującego dołączona jako właściwość tabeli. Może być tylko jeden klucz podstawowy.

W rzeczywistości samo utworzenie nazwanych kluczy kandydujących powinno wystarczyć.

Aby zmienić indeks z klastrowego na nieklastrowany i odwrotnie, wystarczy po prostu znaleźć KLUCZ PODSTAWOWY, który z definicji wynosi co najwyżej 1. Wydaje mi się, że można powiedzieć, że posiadanie PODSTAWOWEJ KLUCZY jest przede wszystkim poczuciem nostalgii dla purystów baz danych. To poczucie czystości bazy danych powinno było wywoływać unikatowe klucze według słów kluczowych KANDYDUJĄCY klucz zamiast rzeczywistych słów UNIKALNY KLUCZ.

Kliknij tutaj, aby zobaczyć definicję klucza kandydującego i komentarze CJDate na ten temat

Nie ma nic do powiedzenia, że ​​klucz podstawowy będzie reprezentował obiekt tabeli. Obiekt tabeli jest indeksem klastrowym, a nie kluczem podstawowym. Nic nie mówi, że klucz podstawowy musi być taki sam jak indeks klastrowany. Często tak jest, ale nie musi tak być. Klucz podstawowy może być łatwo wymuszony przez indeks nieklastrowany.