Używać adresu e-mail jako klucza podstawowego?

234

Czy adres e-mail jest złym kandydatem na adres podstawowy w porównaniu z automatycznym zwiększaniem liczb?

Nasza aplikacja internetowa wymaga, aby adres e-mail był unikalny w systemie. Pomyślałem więc o użyciu adresu e-mail jako klucza podstawowego. Jednak mój kolega sugeruje, że porównanie ciągów będzie wolniejsze niż porównanie liczb całkowitych.

Czy to ważny powód, aby nie używać wiadomości e-mail jako klucza podstawowego?

Używamy PostgreSQL.

Robert
źródło
5
Co rozumiesz przez „podstawowy”? Jeśli adres e-mail musi być unikalny, jest to klucz i wymaga unikalnego ograniczenia. To, czy zdecydujesz się „promować”, to być „podstawowym”, jest arbitralne, chyba że istnieje praktyczny powód, aby to zrobić, np. Optymalizacja źle działającego systemu.
onedaywhen
7
Jeśli chcesz, aby baza danych wymuszała unikalny adres e-mail, utwórz kolumnę z unikalnym indeksem, ale nie używaj go jako klucza podstawowego.
James Westgate
104
@robert Co jeśli ktoś chce zmienić swój adres e-mail? Czy zamierzasz również zmienić wszystkie klucze obce?
systempuntoout
3
@onedaywhen - prawie żadna różnica, ale klucz podstawowy będzie domyślnie klastrowany, podczas gdy unikalny indeks nie będzie. Nadal będziesz chciał zdefiniować klucz podstawowy, który będzie domyślnym kluczem wyszukiwania pojedynczego rekordu, unikalny indeks jedynie wymusza unikalność kolumny nad normalnym indeksem
James Westgate
3
@James Westgate: FYI, w PostgreSQL nie ma czegoś takiego jak automatyczne klastrowanie. KLUCZ PODSTAWOWY jest implementowany na dysku dokładnie tak samo, jak UNIKALNY INDEKS, w którym wszystkie pola NIE SĄ NULL.
Matthew Wood,

Odpowiedzi:

283

Porównanie ciągów jest wolniejsze niż porównywanie int. Nie ma to jednak znaczenia, jeśli po prostu pobierzesz użytkownika z bazy danych przy użyciu adresu e-mail. Ma to znaczenie, jeśli masz złożone zapytania z wieloma połączeniami.

Jeśli przechowujesz informacje o użytkownikach w wielu tabelach, kluczami obcymi do tabeli użytkowników będzie adres e-mail. Oznacza to, że przechowujesz adres e-mail wiele razy.

Sjoerd
źródło
11
@ Sjoerd: Problemem nie jest to, że adres e-mail jest przechowywany wiele razy, chociaż jest to zdecydowanie nieefektywne, ale kogo dzisiaj obchodzi miejsce na dysku twardym. Większość firm nie ma google-skala, co miałoby to znaczenie. Problem polega na tym, że adresu e-mail nie można później zmienić, ponieważ jest to zarówno klucz podstawowy, jak i klucz obcy.
Stefan Steiger,
@StefanSteiger Kto powiedział coś o miejscu na dysku twardym? Wszystko, co przechowujesz, zajmie miejsce w pamięci RAM.
Jonathan Allen,
W przypadku, gdy ktoś zastanawia się, tak jak ja, klucz GUID byłby równoważny kluczowi e-mail.
tofutim
178

Zwrócę również uwagę, że e-mail to zły wybór, aby stworzyć unikalne pole, ponieważ ludzie, a nawet małe firmy, mają wspólny adres e-mail. Podobnie jak numery telefonów, e-maile mogą zostać ponownie wykorzystane. [email protected] może z łatwością należeć do Johna Smitha rok, a Julii Smith dwa lata później.

Innym problemem związanym z wiadomościami e-mail jest to, że często się zmieniają. Jeśli dołączasz do innych tabel z tym kluczem, musisz także zaktualizować inne tabele, co może być dość dużym spadkiem wydajności, gdy cała firma kliencka zmienia swoje e-maile (co widziałem).

HLGEM
źródło
47
+1 za wzmiankę o problemie z aktualizacją kaskadową. Właśnie dlatego przyjaciele pozwalają znajomym używać tylko kluczy zastępczych ;-).
sleske
10
ah, nie podoba mi się to powiedzenie ... klucze zastępcze mogą być również źródłem problemów; tak, aplikacja będzie bardziej odporna na zmianę reguł biznesowych i / lub zasad uczciwości, jednak informacje mogą zostać nieco utracone, a tożsamość zapisów staje się mniej wyraźna. więc nie poleciłbym tutaj kciuka ...
Nieuzasadniony
12
@onedaywhen i @jay, tylko dlatego, że uważasz, że powinien być wyjątkowy, nie czynią go wyjątkowym. I tak, mąż i żona mogą być różnymi klientami. To, że nie spotkałeś się z tym wcześniej, nie oznacza, że ​​tak się nie stanie. Natknąłem się na to i zdarza się, dlatego e-mail nigdy nie powinien być uważany za wyjątkowy, niezależnie od tego, czy tak jest, czy nie. Jest to rodzaj wymogu, który odrzucasz, ponieważ jest z natury zły.
HLGEM
15
@HLGEM: Nie chcę wdawać się w niekończący się spór, ale nie można powiedzieć, że proponowany klucz nie jest unikalny na podstawie hipotetycznych bez znajomości kontekstu. np. z punktu widzenia firmy telefonicznej z definicji numer telefonu jednoznacznie identyfikuje klienta. Tak, możesz powiedzieć: „A co, jeśli dwie lub trzy osoby będą mogły odebrać połączenie pod tym numerem?” Ale to nie ma znaczenia. Z punktu widzenia firmy telefonicznej z definicji jest to jeden klient. (ciąg dalszy ...)
Jay
14
(ciąg dalszy) Podobnie, jeśli budujesz system, który w dużej mierze zajmuje się komunikacją e-mailową - być może system wysyłania wiadomości lub system przekazywania powiadomień - prawdopodobnie adres e-mail z definicji jednoznacznie identyfikuje użytkownika. Jeśli wiele osób udostępnia ten adres e-mail, nie ma to znaczenia. Są miejscem docelowym pojedynczej wiadomości, dlatego są pojedynczym użytkownikiem. „Użytkownik” i „klient” nie muszą być synonimami „indywidualnego człowieka”.
Jay
99

klucz podstawowy powinien być unikalny i stały

adresy e-mail zmieniają się jak pory roku. Przydatny jako klucz pomocniczy do wyszukiwania, ale zły wybór klucza podstawowego.

Steven A. Lowe
źródło
17
Właściwością dobrego klucza jest to, że powinien być stabilny, ale niekoniecznie niezmienny.
poniedziałek
5
@onedaywhen: Tak! W przeciwnym razie dlaczego SQL miałby obsługiwać aktualizacje kaskadowe?
Bill Karwin
18
jeśli masz wybór, wybierz stałe / niezmienne klucze; mniej pracy dla ciebie na drodze; tylko dlatego, że SQL obsługuje kaskadowe aktualizacje, nie oznacza, że ​​to zawsze dobry pomysł!
Steven A. Lowe
7
@Vincent Malgrat: „kaskadowe aktualizacje ... hamują normalizację db” - wydaje się, że źle zrozumiałeś pojęcie normalizacji!
poniedziałek
5
@Vincent Malgrat: dziękuję za potwierdzenie, że rzeczywiście źle zrozumiałeś pojęcie normalizacji. „nie powinieneś powtarzać tych samych informacji w wielu wierszach” - czy naprawdę chciałeś powiedzieć „informacja” ?! Klucz złożony zwykle obejmuje wartości powtarzane w wielu wierszach. W przypadku klucza obcego wartości są przywoływane, a nie „powtarzane”, duża różnica. Domena z jedną kolumną z dwiema wartościami (np. „Tak” i „Nie”) będzie miała takie same wartości w wielu wierszach w tabeli odwołań, jeśli ma trzy lub więcej wierszy. To naprawdę podstawowe rzeczy!
onedaywhen
64

Wady używania adresu e-mail jako klucza podstawowego:

  1. Wolniej podczas łączenia.

  2. Każdy inny rekord z zaksięgowanym kluczem obcym ma teraz większą wartość, zajmując więcej miejsca na dysku. (Biorąc pod uwagę dzisiejszy koszt miejsca na dysku, jest to prawdopodobnie trywialny problem, z wyjątkiem tego, że odczyt zajmuje teraz więcej czasu. Patrz nr 1).

  3. Adres e-mail może ulec zmianie, co wymusza aktualizację wszystkich rekordów używających go jako klucza obcego. Ponieważ adres e-mail nie zmienia się tak często, problem z wydajnością jest prawdopodobnie niewielki. Większy problem polega na tym, że musisz go zapewnić. Jeśli musisz napisać kod, jest to więcej pracy i wprowadza możliwość błędów. Jeśli silnik bazy danych obsługuje „kaskadę aktualizacji”, jest to drobny problem.

Zalety używania adresu e-mail jako klucza podstawowego:

  1. Możesz być w stanie całkowicie wyeliminować niektóre złączenia. Jeśli wszystko, czego potrzebujesz z „rekordu głównego”, to adres e-mail, to przy abstrakcyjnym kluczu całkowitym musisz wykonać połączenie, aby go odzyskać. Jeśli klucz to adres e-mail, oznacza to, że już go masz, a przyłączenie jest niepotrzebne. To, czy ci to pomoże, zależy od częstotliwości tej sytuacji.

  2. Podczas wykonywania zapytań ad hoc człowiek może łatwo zobaczyć, do jakiego wzorca się odnosi. Może to być bardzo pomocne podczas próby śledzenia problemów z danymi.

  3. I tak prawie na pewno będziesz potrzebować indeksu na adres e-mail, więc uczynienie go kluczem podstawowym eliminuje jeden indeks, poprawiając w ten sposób wydajność wstawiania, ponieważ teraz mają tylko jeden indeks do aktualizacji zamiast dwóch.

Moim skromnym zdaniem, tak czy inaczej, nie jest to zwykły trzask. Wolę używać kluczy naturalnych, gdy jest dostępny praktyczny, ponieważ są one po prostu łatwiejsze w użyciu, a wady w większości przypadków nie mają większego znaczenia.

Sójka
źródło
@ Conrad: Chociaż podkreśla, że ​​to nie jest PITA, jeśli masz silnik, który obsługuje ON UPDATE CASCADE. W tym momencie nie jest to problem kodowy; jedynym prawdziwym problemem jest to, jak obszerna jest aktualizacja i jak szeroki jest klucz. Adres e-mail może być trochę większy, ale AKTUALIZACJA KASKADY dla PK 2-znakowego kodu kraju nie jest wielkim problemem.
Matthew Wood,
5
@Matthew IMHO to nadal PITA. Załóżmy na przykład, że kiedy zaprojektowałeś tabelę kraju, były tylko dwie tabele, które się do niej odwoływały, to nic wielkiego, ale z czasem stało się 20 tabel z setkami tysięcy rekordów. Niektóre z odniesieniem niektóre bez. To sprawia, że ​​pojedyncze zapisywanie logiczne kończy się na dziesiątkach tysięcy zapisów i nie trafia do wszystkich tabel, ponieważ ktoś zapomniał o referencji podczas dodawania tabeli. Dokładnie tak się stało na 2-znakowej tabeli kodów krajów, nie żartuję.
Conrad Frix
@Wood & Conrad: Najgorszym przypadkiem jest brak wbudowanej obsługi DB. Następnie musisz napisać dla niego kod dla każdego stołu z opublikowanym odnośnikiem, a to tylko ból i drzwi dla błędów, w które można się wsunąć. W przypadku kaskad trzeba tylko pamiętać o dodaniu jednej klauzuli na każdym stole, a nie takiej wielka sprawa.
Jay
2
Zaletą 1 i 3 są przedwczesne optymalizacje, zaletą 2 jest bardzo niewielka zaleta i jest całkowicie przezwyciężona przez jakiekolwiek przyzwoite narzędzie do zapytań.
Ash
4
@ Ash: Różnica między „optymalizacją” a „przedwczesną optymalizacją”. Ale okej, z tego samego powodu wszystkie wady, o których wspominałem, to przedwczesne optymalizacje. Więc gdzie cię to opuszcza? Jeśli chodzi o # 2, uważam, że wpisywanie dodatkowych złączeń podczas próby wykonywania zapytań ad hoc jest poważnym problemem. Rekordy często mają wiele kluczy obcych, więc może być konieczne kilka połączeń, aby uzyskać zrozumiałe dane. Jeśli przez „narzędzie przyzwoitego zapytania” rozumiesz takie, które dowiedzieć się, jakie dane chcesz zobaczyć bez Twojej wiedzy i magicznie wykonuje dla ciebie połączenia, chciałbym zobaczyć, jak to działa.
Jay
12

Jest całkiem źle. Załóżmy, że jakiś dostawca poczty e-mail przestaje działać. Użytkownicy będą wtedy chcieli zmienić swój adres e-mail. Jeśli użyłeś e-maila jako klucza podstawowego, wszystkie klucze obce dla użytkowników będą duplikować ten e-mail, co bardzo trudno zmienić ...

... i nawet nie zacząłem mówić o kwestiach dotyczących wydajności.

meriton
źródło
W jaki sposób zmiana adresów e-mail może powodować duplikaty? Chyba że użytkownik A zmieni swój adres e-mail, a następnie użytkownik B zmieni jego e-mail na taki sam, jak stara wartość użytkownika A, a aktualizacje nie będą wykonywane po kolei. Zdaje się, że to możliwe.
Jay
2
Odwołanie do klucza obcego z definicji zawiera wartość klucza podstawowego wiersza, do którego się odnosi. Innymi słowy, duplikuje wartość klucza podstawowego. (Więc powielanie nie jest spowodowane przez zmianę wartości. Ale zmiana jest trudniejsza ze względu na to powielanie i wymuszające je ograniczenie).
meriton
5
+1 za wiersz „Załóżmy, że jakiś dostawca poczty e-mail przestaje działać”.
Reddy
To nie jest problem. Aby rozwiązać ten problem, istnieje kaskada z kluczem obcym. Jeśli użytkownik zmieni swój adres e-mail, zmiana zostanie wprowadzona kaskadowo do wszystkich tabel, używając go jako klucza obcego.
Rafa
1
@rafa, zapewniam cię, że jeśli użyjesz aktualizacji kaskadowych, a cały dostawca przestanie działać lub zmieni nazwę (Yahoo.com zmieni się na HooYa.com), twoja baza danych zostanie zablokowana dla wszystkich użytkowników na wiele godzin, a może dni, podczas gdy kaskada przez system. Jest to bardzo ważny problem (i powód, dla którego słabym pomysłem jest stosowanie aktualizacji kaskadowych, jeśli masz znaczną ilość danych, a klucz prawdopodobnie się zmieni.)
HLGEM
12

Nie wiem, czy to może być problem w twojej konfiguracji, ale w zależności od RDBMS w wartościach kolumn może być rozróżniana wielkość liter . Dokumenty PostgreSQL mówią: „Jeśli zadeklarujesz kolumnę jako UNIQUE lub PRIMARY KEY, w niejawnie generowanym indeksie rozróżniana jest wielkość liter”. Innymi słowy, jeśli zaakceptujesz dane wejściowe użytkownika do wyszukiwania w tabeli z e-mailem jako kluczem podstawowym, a użytkownik poda „[email protected]”, nie znajdziesz „[email protected]”.

xlttj
źródło
7
Warto w związku z tym wspomnieć, że [email protected] i [email protected] mogą być tą samą skrzynką pocztową lub mogą być różnymi skrzynkami pocztowymi i nie można powiedzieć, czy w specyfikacji nie ma informacji, czy część lokalna ma wielkość liter. wrażliwy.
telent
Jest to bardziej ogólny problem z wymuszaniem unikalności adresów e-mail, a nie to, czy powinny one być używane jako klucze podstawowe - ten sam problem występuje w obu przypadkach. +1, ponieważ wciąż jest to bardzo przydatny punkt
11

Wydaje się, że nikt nie wspomniał o możliwym problemie, że adresy e-mail można uznać za prywatne. Jeśli adres e-mail jest kluczem podstawowym, najprawdopodobniej będzie wyglądał adres URL strony profilu ..../Users/[email protected]. Co jeśli nie chcesz ujawniać adresu e-mail użytkownika? Trzeba by znaleźć inny sposób identyfikacji użytkownika, na przykład za pomocą unikalnej wartości całkowitej, aby uzyskać podobne adresy URL ..../Users/1. Ostatecznie otrzymałeś unikalną wartość całkowitą.

Simen Echholt
źródło
9

Na poziomie logicznym e-mail jest naturalnym kluczem. W fizycznym poziomie , biorąc pod uwagę, że korzystasz z relacyjnej bazy danych, klucz naturalny nie pasuje do klucza podstawowego. Powodem są głównie problemy z wydajnością wspomniane przez innych.

Z tego powodu projekt można dostosować. Klucz naturalny staje się kluczem alternatywnym (UNIQUE, NOT NULL), a kluczem zastępczym / sztucznym / technicznym jest klucz podstawowy, który może być w twoim przypadku automatyczną inkrementacją.

zapytał systempuntoout,

Co jeśli ktoś chce zmienić swój adres e-mail? Czy zamierzasz również zmienić wszystkie klucze obce?

Po to jest kaskadowanie .

Kolejny powód używania numerycznego klucza zastępczego jako klucza podstawowego jest związany ze sposobem indeksowania na Twojej platformie. Na przykład w InnoDB MySQL wszystkie indeksy w tabeli mają wstępnie przypisany klucz podstawowy, więc chcesz, aby PK był tak mały, jak to możliwe (ze względu na szybkość i rozmiar). Również z tym związane, InnoDB jest szybszy, gdy klucz podstawowy jest przechowywany w sekwencji, a łańcuch nie pomoże.

Inną rzeczą, którą należy wziąć pod uwagę, używając łańcucha jako klucza alternatywnego, jest to, że użycie skrótu rzeczywistego łańcucha, który chcesz, może być szybsze, pomijając takie rzeczy, jak wielkie i małe litery niektórych liter. (Właściwie wylądowałem tutaj, szukając referencji, która potwierdzi to, co właśnie powiedziałem; wciąż szukam ...)

Rafa
źródło
5

Tak, to zły klucz podstawowy, ponieważ użytkownicy będą chcieli zaktualizować swoje adresy e-mail.

Bryan Legend
źródło
1
Myślałem, że
zwrócę
4

tak, lepiej jest zamiast tego użyć liczby całkowitej. możesz również ustawić kolumnę e-mail jako unikalne ograniczenie.

lubię to:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);
ibram
źródło
8
Dlaczego jest „lepiej”? Jakieś powody lub źródła?
Sjoerd
20
Czy możesz to rozwinąć?
Sjoerd
3

Innym powodem, dla którego klucz podstawowy liczby całkowitej jest lepszy, jest odniesienie się do adresu e-mail w innej tabeli. Jeśli sam adres jest kluczem podstawowym, to w innej tabeli musisz go użyć jako klucza. Dlatego przechowujesz adresy e-mail wiele razy.

Klew
źródło
3

Nie znam się zbytnio na postgresie. Klucze podstawowe to duży temat. Widziałem kilka doskonałych pytań i odpowiedzi na tej stronie (stackoverflow.com).

Myślę, że możesz mieć lepszą wydajność, mając numeryczny klucz podstawowy i użyć UNIKALNEGO INDEKSU w kolumnie e-mail. Wiadomości e-mail mają różną długość i mogą nie być odpowiednie dla indeksu klucza podstawowego.

trochę lektury tu i tutaj.

Saif Khan
źródło
3

Osobiście nie używam żadnych informacji na temat klucza podstawowego podczas projektowania bazy danych, ponieważ jest bardzo prawdopodobne, że będę musiał później zmienić jakieś informacje. Jedynym powodem, dla którego podaję klucz podstawowy, jest wygoda wykonywania większości operacji SQL po stronie klienta, a moim wyborem był zawsze automatyczny przyrost liczby całkowitej.

tia
źródło
2

Twój kolega ma rację: użyj liczby całkowitej autoinkrementacji dla klucza podstawowego.

Możesz wdrożyć unikalność wiadomości e-mail na poziomie aplikacji lub możesz oznaczyć kolumnę adresu e-mail jako unikalną i dodać indeks do tej kolumny.

Dodanie pola jako unikalnego będzie kosztować porównanie ciągów tylko podczas wstawiania do tej tabeli, a nie podczas wykonywania połączeń i sprawdzania ograniczeń klucza obcego.

Oczywiście należy pamiętać, że dodanie jakichkolwiek ograniczeń do aplikacji na poziomie bazy danych może spowodować, że aplikacja stanie się nieelastyczna. Zawsze rozważaj, zanim dowolne pole będzie „unikatowe” lub „niepuste” tylko dlatego, że Twoja aplikacja musi być unikalna lub niepusta.

jrharshath
źródło
1
„Zawsze rozważaj przed wdrożeniem wymagania x tylko dlatego, że twoja aplikacja potrzebuje wymagania x”. - najgorsza rada, jaką przeczytałem od dłuższego czasu.
onedaywhen
Nie przekonuje mnie twój „argument” - w prawdziwym życiu często zdarzają się sytuacje, w których niektóre niezbędne dane (np. Numer telefonu) nie będą natychmiast dostępne. Jeśli takie pole jest oznaczone w bazie danych jako NIE NULL, będzie wymagało od użytkowników zanieczyszczenia danych za pomocą atrapy pól (np. 123) zamiast pozostawienia go pustego. Bardziej praktyczne byłoby zezwolenie aplikacji na obsługę ograniczeń (w tym przypadku aplikacja mogłaby oflagować puste pole jako element akcji).
jrharshath
5
Zgadzam się, że zdefiniowanie pola „nie zerowy” powinno być dokonywane ostrożnie. Wymagania takie jak „zawsze potrzebujemy numeru telefonu klienta” należy dokładnie rozważyć. Czy czasem nie jest pożądane tworzenie rekordu klienta, nawet jeśli nie znamy teraz numeru telefonu, i wrócić i go później? Ale „to pole musi być unikalne” to inna kategoria. Nie wyobrażam sobie, żeby powiedzieć „W porządku, jeśli dwóch pracowników ma ten sam numer ubezpieczenia społecznego, ustalimy to później”. Jak wyprostowałbyś dane?
Jay
1
Be Wolves: Znałem kiedyś kobietę, która nie miała własnego numeru telefonu. Co wtedy robisz
David Thornley,
@DavidThornley Wygląda na to, że powinieneś więcej ćwiczyć, a może dostosować bardziej przyjazne zachowanie.
Philip Schiff
2

Użyj GUID jako klucza podstawowego ... w ten sposób możesz wygenerować go ze swojego programu, kiedy wykonasz INSERT i nie musisz otrzymywać odpowiedzi z serwera, aby dowiedzieć się, jaki jest klucz podstawowy. Będzie również unikatowy dla wszystkich tabel i baz danych i nie musisz się martwić, co się stanie, jeśli pewnego dnia obetniesz tabelę, a automatyczny przyrost zostanie zresetowany do 1.

JoelFan
źródło
2
Jeśli nie zależy ci na wydajności, użyj GUID. Nie jest to nr 1, jeśli budujesz system, który będzie wymagał skalowania
Micheasza
no ... zobacz davybrion.com/blog/2009/05/...
JoelFan
3
Powiedziane w prawdziwy sposób picia alkoholu przez Microsoft-Kool!
Gary Chambers,
2

Wiem, że to trochę spóźniony wpis, ale chciałbym dodać, że ludzie porzucają konta e-mail, a usługodawcy odzyskują adres, umożliwiając innym osobom korzystanie z niego.

Jak zauważył @HLGEM, „[email protected] może z łatwością należeć do Johna Smitha rok, a Julii Smith dwa lata później”. w takim przypadku, jeśli John Smith chce twojej usługi, musisz albo odmówić użycia jego adresu e-mail, albo usunąć wszystkie dane dotyczące Julii Smith.

Jeśli musisz usunąć zapisy, które odnoszą się do historii finansowej firmy, w zależności od lokalnych przepisów, możesz znaleźć się w gorącej wodzie.

Dlatego nigdy nie użyłbym danych, takich jak adresy e-mail, numery rejestracyjne itp., Jako kluczy podstawowych, ponieważ bez względu na to, jak wyjątkowe wydają się one poza twoją kontrolą i mogą stanowić ciekawe wyzwania, z którymi możesz nie mieć czasu.

Robert
źródło
2

Konieczne może być rozważenie wszelkich obowiązujących przepisów dotyczących regulacji danych. Adres e-mail to dane osobowe, a jeśli na przykład Twoi użytkownicy są obywatelami UE, zgodnie z RODO mogą nakazać Ci usunięcie ich danych z twoich danych (pamiętaj, że ma to zastosowanie niezależnie od kraju, w którym mieszkasz).

Jeśli chcesz zachować sam rekord w bazie danych ze względu na integralność referencyjną lub ze względów historycznych, takich jak audyt, użycie klucza zastępczego pozwoliłoby Ci na zerowanie wszystkich pól danych osobowych. Nie jest to oczywiście takie łatwe, jeśli ich dane osobowe są kluczem podstawowym

Stuart Parker
źródło
1

możesz zwiększyć wydajność za pomocą liczb całkowitych klucza podstawowego.

xport
źródło
1

powinieneś użyć liczbowego klucza podstawowego. jeśli potrzebujesz, aby kolumna e-mail była unikalna, dlaczego po prostu nie ustawisz indeksu unikatowego dla tej kolumny?

oezi
źródło
1

Jeśli jako klucz podstawowy masz wartość inną niż int, wstawianie i pobieranie będzie bardzo powolne w przypadku dużych danych.

Amareswar
źródło
1
Nie, wstawianie będzie wolniejsze , ponieważ potrzebujesz dwóch unikalnych indeksów: jednego na wygenerowanym kluczu podstawowym i drugiego na adres e-mail.
a_horse_w_no_name
1

klucz podstawowy należy wybrać atrybut statyczny. Ponieważ adresy e-mail nie są statyczne i mogą być współużytkowane przez wielu kandydatów, więc używanie ich jako klucza podstawowego nie jest dobrym pomysłem. Ponadto adresy e-mail są ciągami zwykle o określonej długości, które mogą być większe niż unikatowe identyfikatory, których chcielibyśmy użyć [len (adres_adresu)> len (unikalny_id)], więc wymagałoby to więcej miejsca, a nawet najgorsze, są przechowywane wielokrotnie jako klucz obcy . W konsekwencji doprowadzi to do pogorszenia wydajności.

użytkownik2719152
źródło
0

To zależy od stołu. Jeśli wiersze w tabeli reprezentują adresy e-mail, to adres e-mail jest najlepszym identyfikatorem. Jeśli nie, to adres e-mail nie jest dobrym identyfikatorem.

Lajos Arpad
źródło
0

Jeśli po prostu wymagasz, aby wiadomość e-mail była unikalna, możesz po prostu utworzyć unikalny indeks z tą kolumną.

Micheasz
źródło
0

Adres e-mail jest dobrym unikalnym kandydatem na indeks, ale nie w przypadku klucza podstawowego, jeśli jest to klucz podstawowy, nie będzie można na przykład zmienić adresu e-mail kontaktu. Myślę, że twoje zapytania dotyczące łączenia również będą wolniejsze.

Czekoladki
źródło
0

nie używaj adresu e-mail jako klucza podstawowego, zachowaj adres e-mail jako unikalny, ale nie używaj go jako klucza podstawowego, użyj identyfikatora użytkownika lub nazwy użytkownika jako klucza podstawowego

Nikki
źródło