Czy klucz zastępczy powinien być kiedykolwiek udostępniony użytkownikowi?

14

Często w tabeli, która nie ma naturalnego klucza, nadal przydatne jest, aby użytkownicy mogli mieć unikatowo wygenerowany identyfikator. Jeśli tabela ma zastępczy klucz podstawowy (a w takim przypadku na pewno byś się tego spodziewał), czy klucz ten powinien zostać udostępniony użytkownikowi, czy też powinno się w tym celu użyć innego pola?

Jednym z powodów, dla których nie należy ujawniać klucza zastępczego jest to, że teraz nie można wykonywać operacji, które zachowują związek między rekordami, ale zmieniać wartości kluczy, takie jak niektóre rodzaje usuwania / ponownego wstawiania, wiele metod kopiowania danych z jednej bazy danych do inny itp.

Główną zaletą ujawnienia klucza zastępczego jest prostota korzystania z pola, które i tak masz.

W jakich okolicznościach lepiej jest bezpośrednio udostępniać klucz zastępczy użytkownikom?

— psr
źródło

Częścią tego pytania jest to, że musisz zdefiniować „użytkowników”. Użytkownicy mogą być konsumentami interfejsu API, który udostępniasz, lub mięsistymi ludźmi. Odpowiedź nie będzie taka sama dla obu stron.

— James Snell,

1

Mięsiste istoty ludzkie.

— psr

Każda sytuacja, w której dane mogą być zidentyfikowane inaczej, powinna mieć inny identyfikator. Tak więc, jeśli nowy system łączy się z Twoimi danymi, spodziewaj się, że będzie miał własną PK i doda to do twoich danych. Widoczność „brzydkich worków zawierających głównie wodę” liczy się jako „system” w tym scenariuszu. Moim preferowanym rozwiązaniem jest przechowywanie kluczy i znaczników czasu (dodawanie i zmienianie oraz usuwanie) dla podmiotów w specjalnej tabeli. W ten sposób dane mogą być łatwo dystrybuowane.

10

Musisz być przygotowany na każdy identyfikator, który zostanie ujawniony użytkownikom / klientom wymagającym zmiany, a zmiana tożsamości wiersza w bazie danych i propagowanie tej zmiany do wszystkich kluczy obcych wymaga jedynie przerwania danych.

Jeśli dane nie mają naturalnego klucza biznesowego, możesz dodać dodatkowe pole dla „identyfikatora biznesowego”. Należy to zoptymalizować pod kątem procesów, w których jest używany. Wprowadzanie za pomocą klawiatury telefonicznej oznacza tylko cyfrę. Przez telefon / środki werbalne unikaj podobnych dźwięków (B / D, M / N itp.). Możesz nawet wygenerować automatycznie łatwą do zapamiętania frazę („zielona galaretka”).

Skutkuje to tym, że firma może później zmienić sposób, w jaki chcą odwoływać się do rekordów, a jedyną zmianą schematu danych jest albo dodanie nowej kolumny dla tego stylu identyfikatora, albo przekształcenie już istniejących identyfikatorów. Zmiana nie rozprzestrzenia się w całej bazie danych, a nadal masz jeden identyfikator (zastępczy), który jest ważny w czasie.

Krótko mówiąc, unikałbym udostępniania użytkownikom kluczy zastępczych. Jak wskazują komentarze, klucze zastępcze prawie nigdy nie powinny się zmieniać. I odwrotnie, firmy chcą wszystko zmienić. Jeśli klucz zastępczy zostanie ujawniony, to tylko kwestia czasu, zanim firma będzie chciała go zmienić.

Na marginesie, kiedy mówię tutaj „ujawniając”, mam na myśli dać klucz użytkownikowi, oczekując, że użyje go bezpośrednio (jak zadzwonienie w celu wsparcia z numerem zamówienia).

— Chris Pitman
źródło

5

Ta odpowiedź nie ma sensu. Klucze zastępcze nigdy się nie zmieniają, a Ty nie uzasadniłeś, że nie udostępniasz ich użytkownikom.

— Robert Harvey

1

nigdy nie mów nigdy. co jeśli ten ostatni projekt prowadzi do konsolidacji rekordów? co zrobić, jeśli chcesz zwiększyć rozmiar i zmienić tożsamość?

— DougM,

3

@DougM: Następnie zapisz rekordy do nowej skonsolidowanej tabeli z własnym kluczem zastępczym i zachowaj oryginalne klucze w osobnych polach w nowej tabeli (i polu identyfikującym oryginalną tabelę źródłową) jako odniesienia, jeśli to konieczne. Tego rodzaju konsolidacja powinna być niezwykle rzadka i tylko w wyniku nieudanego projektu. Powtórz za mną: surogat. Klucze. Nigdy. Zmiana. Dlatego są surogatami.

— Robert Harvey

2

@RobertHarvey Zgadzam się, że klucze zastępcze nigdy nie powinny się zmieniać, dlatego myślę, że tworzą słabe zewnętrzne identyfikatory. W końcu klient będzie chciał zmienić sposób , w jaki odnoszą się do rekordu. W tym momencie albo zbudowałeś cały system wokół niezmiennych kluczy zastępczych, albo zastanowiłeś się nad tym i wprowadziłeś poziom pośredni między identyfikatorami biznesowymi a kluczami zastępczymi.

— Chris Pitman

2

@sqlvogel: Czy to by było bardziej zrozumiałe, gdybym użył terminu „wygenerowany przez system klucz podstawowy” zamiast „surogat”? Zgadzam się, że możesz chcieć zmienić algorytm generujący klucze zastępcze, ale to nie zmienia ich zasadniczo niezmiennej jakości.

— Robert Harvey

4

W niektórych przypadkach klucze zastępcze są oczekiwane i mają sens dla użytkowników. Moim ulubionym przykładem jest „numer zamówienia”. Numer zamówienia nie jest tak naprawdę kluczem naturalnym: kluczem naturalnym może być znacznik czasu plus użytkownik, a może nawet więcej, jeśli oczekujesz, że użytkownicy wygenerują więcej niż jedno zamówienie w ramach szczegółowości twojego znacznika czasu.

Niemniej użytkownicy rozumieją i oczekują wygody numeru zamówienia. Jeśli poinformujesz użytkowników o nich, nie zaszkodzi i zyskasz na wartości.

Z drugiej strony niektóre klucze zastępcze nie mają sensu dla użytkownika. Jasne, moja firma ubezpieczeń zdrowotnych ma jakiś klucz zastępczy, który identyfikuje mnie na podstawie identyfikatora członka, daty urodzenia, przewoźnika itp., Ale nie dbam o to, dbam o informacje na mojej karcie (które często zawierają identyfikatory u mojego pracodawcy i nie są wyjątkowe w całym wszechświecie ... Stąd klucz zastępczy w firmie ubezpieczeniowej).

— Alan Shutko
źródło

Jeśli użytkownik to zrozumie i spodziewa się interakcji, nie jest to już klucz zastępczy. Klucze zastępcze są zdefiniowane jako niemające znaczenia biznesowego. To, że jest to numer identyfikacyjny, niekoniecznie oznacza, że jest to surogat. Również „jakiś klucz zastępczy, który identyfikuje mnie na podstawie identyfikatora mojego członka, daty urodzenia [...]” nie ma sensu. Mówisz, że ich klucz zastępczy (który nie ma żadnego znaczenia biznesowego) identyfikuje cię na podstawie rzeczy, które mogłyby stanowić naturalny klucz?

— Kyle McVay,

Często zdarza się, że otrzymujesz numer identyfikacyjny pracownika, dzięki czemu w systemie pracowniczym odróżniasz się od innych osób o tym samym nazwisku. Na karcie ubezpieczenia może znajdować się identyfikator Twojej firmy i pracownika. Ale towarzystwo ubezpieczeń zdrowotnych często generuje swój wewnętrzny identyfikator, którego może używać we wszystkich swoich systemach, zamiast używać imienia i nazwiska, daty urodzenia oraz identyfikatorów pracowników otrzymanych od pracodawcy. Czy te wygenerowane klucze są kluczami zastępczymi czy naturalnymi? Zależy od kogo zapytasz (sprawdź 2 alternatywne definicje na en.wikipedia.org/wiki/Surrogate_key )

— Alan Shutko

1

Powinieneś ujawniać klucz zastępczy tylko wtedy, gdy jest to poprawnie wygenerowany identyfikator GUID / UUID *. Ujawnianie sekwencyjnych kluczy zastępczych jest numerem 4 w kwestiach bezpieczeństwa 10 najlepszych OWASP.

* W praktyce najlepiej założyć, że nie został poprawnie wygenerowany do tych celów, chyba że wiesz, że został utworzony przez kryptograficznie bezpieczny generator liczb losowych lub pseudolosowych.

— Peter Taylor
źródło

2

Z odpowiedzi nie jest jasne, w jaki sposób GUID poprawia bezpieczeństwo.

— Robert Harvey

1

@RobertHarvey - Zakładam, że nie są one sekwencyjne i dlatego nie można ich zgadnąć.

— Bobson,

1

security.stackexchange.com/q/38777

— Robert Harvey

@RobertHarvey, wyjaśnione.

— Peter Taylor

1

Jeśli tabela nie ma klucza naturalnego, klucze zastępcze dopuszczają takie wiersze.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Nazwałbym te sztuczne klucze zamiast kluczy zastępczych, ale to rozróżnienie nie jest ważne w przypadku tego pytania.

Teraz, zakładając, że istnieją ważne dane odnoszące się do tych kluczy zastępczych poprzez klucze obce, w jaki sposób użytkownicy końcowi wiedzą, który wiersz zaktualizować, jeśli nie znają wartości kluczy zastępczych?

— Mike Sherrill „Cat Recall”
źródło

Trochę sprzeczne jest oznaczenie kolumny „surrogate_key”, ale następnie powiedzenie, że są to „sztuczne klucze zamiast kluczy zastępczych”. Jeśli wywołujesz te sztuczne klucze, ponieważ nie mają one znaczenia biznesowego i służą jedynie jako unikalne identyfikatory, to ten klucz powinien zostać naturalizowany (ujawniony) i należy utworzyć nowy klucz zastępczy. tj. zmień nazwę naturalizowanego surrogate_key na coś o znaczeniu biznesowym, ujawnij go klientom i utwórz nową podobną kolumnę, aby była prawdziwym zastępstwem operacji wewnętrznych. Mniej niż idealny, ale wciąż lepszy niż ujawnienie prawdziwego surogatu.

— Kyle McVay,

@KyleMcVay: To nie jest sprzeczne. Uwzględnia znaczenie surogatu , którego zasadniczą ideą jest „zastąpić”. A zastępcze kluczowe substytuty klucza naturalnego. (Codd i teoria relacyjna ogólnie używają klucza zastępczego w tym sensie.) Tabela, która nie ma klucza naturalnego, nie może mieć klucza zastępczego w tym sensie. Ale może mieć dowolną wartość, która jest używana zamiast czegokolwiek innego. To właśnie nazwałbym sztucznym kluczem.

— Mike Sherrill „Cat Recall”

Twoje definicje nie są niedokładne, ale myślę, że klucz zastępczy nabrał dodatkowego, specyficznego dla branży znaczenia poza słowem surogat . Jeśli zamierzasz ujawnić klucz klientowi, argumentowałbym, że ten klucz ma teraz znaczenie biznesowe; został naturalizowany i należy go teraz uważać za logicznie część bytu, który reprezentuje. Zgodnie z tą logiką nie ma czegoś takiego jak odsłonięty klucz zastępczy. Jeśli zamierzasz odsłonić sztuczny klucz, nie jest to już klucz zastępczy i potrzebujesz nowego.

— Kyle McVay,

0

Słowami laika:

Surogaty powinny być ukryte przed użytkownikiem.
Powinieneś udostępnić użytkownikowi inny klucz kandydata na biznes.
Jeśli nie istnieje żaden inny klucz kandydujący, powinieneś pokazać PK. Ale w tym przypadku PK nie jest uważane za surogat, ponieważ nie zastępuje innej kolumny.

— Tulains Córdova
źródło

Dlaczego należy pokazać PK? Myślę, że to moje pytanie - czy stuknięcie automatycznie generowanego PK jest nazywane kluczem zastępczym.

— psr

1

@ psr Tytuł pytania brzmi: „ klucze zastępcze kiedykolwiek zostaną ujawnione”. Powiedziałem nie. Ale musisz pokazać inny klucz. Jeśli nie istnieje żaden inny klucz, musisz pokazać jedyny posiadany klucz. Stycznie wyjaśniam, że w takich przypadkach klucz nie jest tak naprawdę surogatem, ponieważ nie zastępuje żadnej innej kolumny.

— Tulains Córdova

Pytanie brzmi, czy powinieneś dodać kolumnę, czy pokazać klucz, który masz.

— psr

@psr Ponownie sformułowałem swoją odpowiedź, aby była bardziej przejrzysta.

— Tulains Córdova

1

Uważam, że jest to istotne nieznacznie rozróżnienie. Jeśli twoja reguła mówi, że każdy stół ma sztuczny klucz (którym jest moja) i że tylko sztuczne klucze uczestniczą w sprzężeniach (co jest również moją zasadą), to pojęcie, że klucz jest surogatem, ponieważ inne klucze mogą być dostępny jest nieistotny.

— Robert Harvey

0

powinieneś ujawniać WYŁĄCZNIE pole użytkownikowi, który dostarcza użyteczne informacje użytkownikowi, bezpośrednio lub w zgłoszeniu usterki.

i odwrotnie, należy ZAWSZE ujawniać „zastępcze klucze podstawowe”, gdy są one głównym sposobem identyfikacji rekordu (prostego lub złożonego) dla interakcji, którą wykonuje użytkownik.

— DougM
źródło

0

Nie powinno mieć znaczenia, czy ujawnisz klucze czy nie użytkownikowi końcowemu. Twoja aplikacja powinna wykonać niezbędną autoryzację, tak aby na przykład znajomość identyfikatora zamówienia nie pozwalała na dostęp do czegoś, do czego normalnie nie mieliby dostępu.

zastrzeżenie: zakłada to aplikację internetową lub n-warstwową, w której autoryzacja po stronie serwera jest możliwa / wykonalna. Jeśli masz aplikację VB, która bezpośrednio wykonuje SQL, jest to zupełnie inny problem.

— Grandmaster B.
źródło

Co powiesz na niemożność wstawiania, a następnie usuwania rekordów, zachowując relacje między kluczami obcymi, jak wspomniano w pytaniu?

— psr

Co to ma wspólnego z ujawnieniem klucza użytkownikowi? Może nie rozumiem twojego użycia terminu „ujawnianie”. Pracuję z założenia, że masz na myśli „być widocznym dla użytkownika”.

— GrandmasterB