Witam,
Zastanawiam się nad dobrą praktyką w następującej sytuacji:
a) mamy pola, które chcemy przechowywać w tabeli a|b|c|d
b) generalnie ich kombinacja musi być unikalna
Pozdrawiam,
Jeszcze nie spotkałem się z sytuacją, w której naturalny klucz byłby dobrym rozwiązaniem. Prędzej czy później okazuje się, że natura nas oszukała i na klucz się nie nadaje.
Ja z kolei zaczalem uzywac naturalnych kluczy i czesto okazywalo sie to bardzo dobrym designem z perspektywy czasu: bylo prosciej, poniewaz nie musialem uzywac redundantnych indeksow do utrzymania unikalnosci pewnych wartosci. Zgadzam sie, ze nie zawsze oczywiste jest co powinno byc kluczem. I wtedy lepiej wybrac klucz techniczny.
Tutaj mam dylemat. Bo tych kolumn jest duzo. I tak musza byc unikalne. Zaleta stosowana unikalnego indeksu jest fakt, ze latwiej go zmienic niz composite primary key.
To zależy, ale ja bym skłaniał się, ku tezie, że klucze 'sztuczne' są lepsze.
W Twojej sytuacji jednak, to w ogóle nie ma o czym mówić.W każdej tabeli w której będziesz się odwoływał do tej z z kluczem głównym abcd będziesz dokładał 4 kolumny, jak zaczniesz tworzyć joiny też będzie ciekawie.Jeżeli stworzysz klucz główny generowalny nadasz mu nawet typ bigint-8 byte to w 90 % przypadkach to będzie mniej niż suma bajtów w tych kolumnach tworzących klucz główny a co za tym idzie będzie lepsza wydajność.
Nie kombinowałbym ;-)
Jeśli system na to pozwala to zakładaj wszędzie techniczny.
A zamiast naturalnego klucza załóż unikalny indeks.
Zalety:
Klucz naturalny z czterech kolumn to porażka. Choć jestem zwolennikiem kluczy naturalnych to jednak nie tym razem. Przy takiej ilości kolumn nie masz gwarancji, że w przyszłości nic się nie zmieni.
w systemach comarchu tabele mają klucze naturalne od 1 do 5 kolumn (Numer, Typ, Firma, Lp, SubLp) - przy czym te z 1 kolumną i tak mają 4 kolumny do klucza, po prostu z wersji na wersję przeszli z klucza naturalnego na 4 kolumny na klucz na 1 kolumnę
powiem z doświadczenia że to baaardzo wkurzające i złe rozwiązanie - kolumn w tabelach jest mnóstwo, śmietnik ogromny, joiny pisze się niewygodnie, indeksy są pozakładane losowo - w każdej tabeli trzeba patrzeć na które z tych 4 / 5 kolumn jest założony klucz żeby nie muliło - w dodatku zmienia się to z wersji na wersje
ja patrzę na to tak - jak będę musiał usunąć albo zmienić rekord to muszę podać np. 4 ciągi znaków, czego mi się nie będzie chciało, zamiast jednego id. Natomiast używam też kluczy naturalnych ale na pojedynczych polach, w porywach do dwóch (np. tabele łączące relacje n-m)
Rozwiązanie z dużym kluczem jest świetne, bo nikomu nie będzie się chciało robić joinów, jak nie będzie mieć rzeczywiście powodu. Joiny to zło. Ja tu widzę samy plusy. ;)
Stosując klucz sztuczny nadawany po sekwencji zwalniasz się z odpowiedzialności i myślenia o tym czy coś jest unikalne czy nie.
No chyba, że jesteś ekspertem w danej dziedzinie... Ale często możesz się mocno pomylić. np. pesel nie jest unikalny, albo ja w poprzedniej robocie jako klucz miałem kod pocztowy, tylko, że są kody, pod którymi jest 7 wiosek... i teraz weź popraw system magazynowy, księgowy i wszystko inne w starej gównianej technologii bez testów...
Dlatego ja zawsze daje klucze sztuczne
Klucz może być szybszy, ale faktycznie może oszukać i wyjdzie kłamstwo. A przez to że wyjdzie zły wynik znów trzeba zrobić na nowo obliczanie, czy doświadczanie. To jest Syzyfowa praca. Najlepiej jak masz czas zrobić z kluczem i bez klucza i sam zobaczysz czy będą aż tak wielkie różnice.