Mam nietypowe pytanie
Otóż mam takie przyzwyczajenie że zawsze do każdej tabeli dodaje pole ID auto increment, ale czy to jest dobra praktyka? np przy systemie logowania i tak nazwa użytkownika czy email musi być unikalny więc na co komu pole ID? Kiedyś ktoś mocno przekonywał mnie że zawsze warto dodać takie unikalne i jednoznaczne pole ID w tabeli, ale czy aby na pewno ?

pozdrawiam

Generalnie, warto. Koszt dodania takiej kolumny jest niemal zerowy, a jest to mimo wszystko najwygodniejszy sposób identyfikacji rekordów.

A warto dlatego, że lepiej operować na liczbach niż stringach. Choćby dlatego, że liczby są ułożone w ściśle określony sposób i wiesz, że po 1 wystąpi 2 (zakładając brak dziur w rekordach), a stringi trzeba najpierw posortować alfabetycznie.

@Fifi209: Tekst to nic innego jak ciąg liczb, a indeksy w obu przypadkach muszą być posortowanie. Na dobrą sprawę indeks kolumny tekstowej też jest numeryczny.

Jednym słowem jedyny plusem jest to że przetwarzając rekord po pobraniu z bazy posługujmy się krótkim nr ID a nie dłuższym stringiem...

@Crozin, @Fifi: w większości przypadków pole primary z autoincrement ma sens, ale nie zawsze. Dla mnie w przypadku choćby tabeli łączącej dla relacji many-2-many nie ma to sensu. Niby po co by miała tam taka kolumna być? Tam gdzie faktycznie trzeba identyfikować pojedyncze wiersze, ma to sens. A więc tabele userów, newsów, komentarzy, artykułów czy czego tam się chce mają uzasadnione istnienie takiej kolumny. Tak samo tabele skrajne dla złączenia, ale już dla tabeli łączącej jest to zbędne. Bo niby czemu mielibyśmy identyfikować konkretne złączenie, które w przypadku wspomnianej many-2-many może być zaledwie jednym z większej ilości dopasowań dla elementu po jednej ze stron.

@thek: Sytuacji, gdzie klucze główne są złożone nie brałem pod uwagę. Znalazło by się jeszcze kilka innych przykładów gdzie wrzucanie ID nie ma sensu, ot chociażby tabele z tłumaczeniami (id_zasobu, id_języku) czy nadrzędna relacja 1-1.

INDEXY na strinach działają tylko w pewnych sytuacjach w sensie faktycznie przyśpieszają przeszukiwanie. Warto doczytać dokumentacje. Wyszukanie rekordu po id gdzie primary jest z pewnością dużo szybsze. Tak samo z edycją. Dlatego zawsze warto, pomijając tabele o których była mowa.

Pozdrawiam

I właśnie dlatego o tych sytuacjach wspomniałem. Niech autor wie, że są takowe sytuacje, gdzie wrzucanie klucza primary z autoincrement nie ma sensu i jedyne co robi to tworzy zbedny indeks. Ba, całą zbędną kolumnę. My raptem podaliśmy pewne warianty najpowszechniejsze, gdzie podejście autora nie ma racji bytu.

W sumie zmieniłbym nawet zdanie i powiedział że jest sens zawsze chociażby ze względu na prędkość złączenia za pomocą klucza, jeśli złączenie nie po kluczu to i tak edycja szybsza. Poza tym chciałbym jeszcze dodać że w praktyce rozróżnianie userow po e-mailu bardzo złym pomysłem pomijajac kwestie wspomniane wcześniej. Załóżmy że masz iluś tam użytkowników i masz ich profile. I teraz chcesz mieć link do jego profilu. I co w tedy ? Rozumiem że będziesz wszędzie podawał ich e-maile ; ) Reasumując ja zawsze dodaje to id, nawet jeśli ktoś twierdzi że może do końca to nie ma sensu. Nic Cię to nie kosztuje, a taka pseudo optymalizacja zapewne wywiedzie Cię w pole. Pozdr

A jaki jest konkretny, z życia wzięty przykład tabeli many-2-many, gdzie stosowanie id jest niepotrzebne?

A widziałeś kiedyś tabelę many-2-many z kluczem autoincrement primary założonym na jedną z kolumn? Ja najwyżej z założonym unique na obie jednocześnie. To, że obie kolumny zawierają pola z jakimś id typu int to chyba logiczne. Sednem problemu jest to jaki indeks założono i na jakie kolumny. Przykład tabeli życiowy? Produkt i kategorie w sklepie Jeden produkt może należeć do kilku kategorii, a jednocześnie jedna kategoria może zawierać wiele przedmiotów. Tabela łącząca zawiera id_produktu i id_kategorii, a indeks założony na obie kolumny jednocześnie z atrybutem unique. Implikacje? Chyba nie trzeba przytaczać