Ciągi znaków jako klucze podstawowe w SQL Database

Nie jestem zbyt zaznajomiony z bazami danych i teoriami dotyczącymi ich działania. Czy z punktu widzenia wydajności (wstawianie / aktualizowanie / wysyłanie zapytań) wolniej jest używać ciągów znaków dla kluczy podstawowych niż liczb całkowitych?

Technicznie tak, ale jeśli ciąg ma sens jako klucz podstawowy, prawdopodobnie powinieneś go użyć. Wszystko zależy od rozmiaru tabeli, dla której ją tworzysz, i długości łańcucha, który będzie kluczem podstawowym (dłuższe ciągi == trudniej porównać). Niekoniecznie użyłbym ciągu dla tabeli, która ma miliony wierszy, ale ilość spowolnienia wydajności, którą uzyskasz, używając ciągu na mniejszych tabelach, będzie minimalna w porównaniu z bólami głowy, które możesz mieć, mając liczbę całkowitą, która nie nie mają żadnego znaczenia w odniesieniu do danych.

Innym problemem związanym z używaniem ciągów jako klucza podstawowego jest to, że ponieważ indeks jest stale ustawiany w kolejności sekwencyjnej, kiedy tworzony jest nowy klucz, który byłby w środku kolejności, indeks musi zostać ponownie uporządkowany ... jeśli używasz funkcji auto number integer, nowy klucz jest właśnie dodawany na końcu indeksu.

Wstawia do tabeli mającej indeks klastrowy, w którym wstawienie następuje w środku sekwencji NIE POWODUJE przepisania indeksu. Nie powoduje to przepisywania stron zawierających dane. Jeśli na stronie jest miejsce, do którego trafi wiersz, zostanie on umieszczony na tej stronie. Pojedyncza strona zostanie ponownie sformatowana, aby umieścić wiersz we właściwym miejscu na stronie. Gdy strona jest pełna, nastąpi podział strony, z połową wierszy na jednej stronie, a połową na drugiej. Strony są następnie ponownie łączone z połączoną listą stron, które zawierają dane tabel, które mają indeks klastrowy. Ostatecznie skończysz na zapisaniu 2 stron bazy danych.

Ciągi są wolniejsze w łączeniach iw prawdziwym życiu bardzo rzadko są naprawdę wyjątkowe (nawet jeśli powinny). Jedyną zaletą jest to, że mogą zmniejszyć liczbę złączeń, jeśli dołączasz do tabeli podstawowej tylko po to, aby uzyskać nazwę. Jednak ciągi znaków również często ulegają zmianie, co stwarza problem konieczności naprawiania wszystkich powiązanych rekordów, gdy zmienia się nazwa firmy lub osoba wychodzi za mąż. Może to być ogromny spadek wydajności, a jeśli wszystkie tabele, które powinny być w jakiś sposób powiązane, nie są powiązane (zdarza się to częściej niż myślisz), możesz również mieć niedopasowanie danych. Liczba całkowita, która nigdy się nie zmieni przez cały okres istnienia rekordu, jest o wiele bezpieczniejszym wyborem z punktu widzenia integralności danych, jak również z punktu widzenia wydajności. Klucze naturalne zwykle nie są tak dobre do przechowywania danych.

Chcę również zwrócić uwagę, że najlepszym z obu światów jest często użycie klucza autoinkrementacji (lub w niektórych wyspecjalizowanych przypadkach GUID) jako PK, a następnie umieszczenie unikalnego indeksu na kluczu naturalnym. Otrzymujesz szybsze łączenia, nie otrzymujesz zduplikowanych rekordów i nie musisz aktualizować miliona rekordów podrzędnych, ponieważ zmieniła się nazwa firmy.

Nie ma znaczenia, jakiego używasz jako klucza podstawowego, o ile jest on WYJĄTKOWY. Jeśli zależy Ci na szybkości lub dobrym projekcie bazy danych, użyj int, chyba że planujesz replikować dane, a następnie użyj identyfikatora GUID.

Jeśli jest to baza danych dostępu lub jakaś malutka aplikacja, to kogo to naprawdę obchodzi. Myślę, że powodem, dla którego większość z nas, programistów, uderza stary int lub guid z przodu, jest to, że projekty mają sposób na rozwój i chcesz zostawić sobie możliwość rozwoju.

Za dużo zmiennych. Zależy to od wielkości tabeli, indeksów, charakteru domeny kluczy łańcuchowych ...

Generalnie liczby całkowite będą szybsze. Ale czy różnica będzie na tyle duża, żeby się tym przejmować? Trudno powiedzieć.

Jaka jest Twoja motywacja do wyboru stringów? Często też o wiele łatwiejsze są klawisze numeryczne z automatycznym zwiększaniem wartości . Czy to semantyka? Wygoda? Problemy z replikacją / rozłączeniem? Twoja odpowiedź może ograniczyć twoje opcje. To również przywodzi na myśl trzecią opcję „hybrydową”, o której zapominasz: Guids.

Nie martw się o wydajność, dopóki nie uzyskasz prostego i solidnego projektu, który będzie zgodny z tematem, który opisują dane, i będzie dobrze pasował do zamierzonego wykorzystania danych. Następnie, jeśli pojawią się problemy z wydajnością, możesz je rozwiązać, dostosowując system.

W takim przypadku prawie zawsze lepiej jest użyć ciągu jako naturalnego klucza podstawowego, pod warunkiem, że możesz mu zaufać. Nie martw się, jeśli jest to ciąg, o ile jest on rozsądnie krótki, powiedzmy maksymalnie 25 znaków. Nie zapłacisz dużej ceny pod względem wydajności.

Czy osoby wprowadzające dane lub automatyczne źródła danych zawsze dostarczają wartości dla domniemanego klucza naturalnego, czy też są czasami pomijane? Czy zdarza się, że dane wejściowe są błędne? Jeśli tak, w jaki sposób są wykrywane i naprawiane błędy?

Czy programiści i użytkownicy interaktywni, którzy określają zapytania, są w stanie używać klucza naturalnego, aby uzyskać to, czego chcą?

Jeśli nie możesz zaufać naturalnemu kluczowi, wymyśl surogat. Jeśli wymyślisz surogat, równie dobrze możesz wymyślić liczbę całkowitą. Wtedy musisz się martwić, gdzie ukryć surogat przed społecznością użytkowników. Niektórzy programiści, którzy nie ukryli klucza zastępczego, zaczęli tego żałować.

Indeksy implikują wiele porównań.

Zazwyczaj łańcuchy są dłuższe niż liczby całkowite, a do porównania można zastosować reguły sortowania, więc porównywanie łańcuchów jest zwykle bardziej wymagającym obliczeniowo niż porównywanie liczb całkowitych.

Czasami jednak szybsze jest użycie łańcucha jako klucza podstawowego niż wykonanie dodatkowego sprzężenia z string to numerical idtabelą.

Tak, ale jeśli nie spodziewasz się milionów wierszy, nieużywanie klucza opartego na ciągach znaków, ponieważ jest wolniejszy, jest zwykle „przedwczesną optymalizacją”. W końcu łańcuchy są przechowywane jako duże liczby, podczas gdy klawisze numeryczne są zwykle przechowywane jako mniejsze liczby.

Jedną rzeczą, na którą należy zwrócić uwagę, jest sytuacja, w której masz indeksy klastrowe na dowolnym kluczu i wykonujesz dużą liczbę wstawień, które nie są sekwencyjne w indeksie. Każda napisana linia spowoduje ponowne zapisanie indeksu. jeśli robisz wstawianie wsadowe, może to naprawdę spowolnić proces.

Dwa powody, dla których warto używać liczb całkowitych w kolumnach PK:

1. Możemy ustawić tożsamość dla pola liczb całkowitych, które zwiększało się automatycznie.

2. Kiedy tworzymy PK, baza danych tworzy indeks (Cluster lub Non Cluster), który sortuje dane, zanim zostaną zapisane w tabeli. Używając tożsamości na PK, optymalizator nie musi sprawdzać kolejności sortowania przed zapisaniem rekordu. Poprawia to wydajność przy dużych stołach.

Jaki jest powód posiadania ciągu jako klucza podstawowego?

Po prostu ustawiłbym klucz podstawowy na automatycznie zwiększające się pole liczby całkowitej i umieściłbym indeks w polu ciągu.

W ten sposób, jeśli wyszukujesz w tabeli, powinny one być stosunkowo szybkie, a wszystkie twoje łączenia i zwykłe wyszukiwania pozostaną niezmienione.

Możesz także kontrolować ilość indeksowanego pola tekstowego. Innymi słowy, możesz powiedzieć „indeksuj tylko pierwsze 5 znaków”, jeśli uważasz, że to wystarczy. Lub jeśli Twoje dane mogą być stosunkowo podobne, możesz zindeksować całe pole.

Z punktu widzenia wydajności - ciąg znaków tak (PK) spowolni wydajność w porównaniu z wydajnością uzyskaną przy użyciu liczby całkowitej (PK), gdzie PK ---> klucz podstawowy.

Z punktu widzenia wymagań - chociaż nie jest to część Twojego pytania, to jednak chciałbym wspomnieć. Kiedy obsługujemy ogromne dane w różnych tabelach, zazwyczaj szukamy prawdopodobnego zestawu kluczy, które można ustawić dla określonej tabeli. Dzieje się tak przede wszystkim dlatego, że istnieje wiele tabel i przeważnie każda lub jedna tabela byłaby powiązana z drugą poprzez jakąś relację (pojęcie klucza obcego). Dlatego naprawdę nie zawsze możemy wybrać liczbę całkowitą jako klucz podstawowy, raczej wybieramy kombinację 3, 4 lub 5 atrybutów jako klucz podstawowy dla tych tabel. I te klucze mogą być używane jako klucze obce, gdy odnosimy się do rekordów z inną tabelą. To sprawia, że ​​w razie potrzeby przydatne jest powiązanie rekordów z różnymi tabelami.

Dlatego dla optymalnego wykorzystania - zawsze tworzymy kombinację 1 lub 2 liczb całkowitych z 1 lub 2 atrybutami ciągów, ale ponownie tylko wtedy, gdy jest to wymagane.

Może wystąpić bardzo duże nieporozumienie związane z ciągiem znaków w bazie danych. Prawie każdy pomyślał, że reprezentacja liczb w bazie danych jest bardziej zwarta niż w przypadku łańcuchów. Myślą, że w db-s liczby są reprezentowane jak w pamięci. ALE to nieprawda. W większości przypadków reprezentacja liczb jest bardziej zbliżona do reprezentacji typu string, jak do innych.

Szybkość używania liczby lub łańcucha jest bardziej zależna od indeksowania niż od samego typu.

Domyślnie ASPNetUserIds to ciągi 128 znaków, a wydajność jest dobra.

Jeśli klucz MUSI być unikalny w tabeli, powinien to być Klucz. Dlatego;

podstawowy łańcuch-klucz = poprawne relacje z bazą danych, 1 klucz ciągu (podstawowy) i 1 indeks ciągu (podstawowy).

Inną opcją jest typowy klucz int, ale jeśli łańcuch MUSI być unikalny, prawdopodobnie nadal będziesz musiał dodać indeks z powodu ciągłych zapytań w celu sprawdzenia poprawności lub sprawdzenia, czy jest unikalny.

Tak więc użycie klucza tożsamości int = niepoprawne relacje DB, 1 klucz int (podstawowy), 1 indeks int (podstawowy), prawdopodobnie unikalny indeks ciągu i ręczne sprawdzenie tego samego ciągu nie istnieje (może coś takiego jak sprawdzenie sql ).

Aby uzyskać lepszą wydajność, używając int zamiast ciągu dla klucza podstawowego, gdy łańcuch MUSI być unikalny, musiałaby to być bardzo dziwna sytuacja. Zawsze wolałem używać kluczy typu string. I zgodnie z dobrą zasadą, nie denormalizuj bazy danych, dopóki nie jest to POTRZEBNE .