W jednej z aplikacji, w której przetwarza się dane osobowe etc. widziałem dość ciekawy "patent", a mianowicie zamiast standardowych numerycznych ID w tabeli stosowane są losowe ciągi 40 znaków (przypuszczalnie jakieś md5 z randa). Jeśli dobrze rozumiem intencję autora, to chodzi o to, aby w aplikacji współdzielonej dodać dodatkowe zabezpieczenie np. gdy ktoś w swoim profilu edytując rekord, podmieniłby id na inne i zapisał/odczytał czyjeś rekordy. Oczywiście nie jest to jedyne zabezpieczenia, a bardziej przypuszczam takie utrudnienie dla crackerów, aby już na wstępie mili problem w ustaleniu id rekordu, który chcieliby rozpracować.

I teraz pytanie - jak takie id alfanumeryczne ma się do wydajności mysql? Jest duża różnica między id numerycznym a alfanumerycznym np. w zapytaniach typu left join po id, czy np. w wyszukiwaniu rekordów o danych ID itp?

Podobny patent chciałbym zastosować również u siebie, bo piszę aplikację, gdzie jest na prawdę spory mix uprawnień i czasami sam się gubię, komu co zablokować w danej akcji. Aplikacja wewnętrzna, więc użytkowników raczej nie podejrzewam o umiejętności hakerskie, ale wiadomo nawet małpa umie podmienić ID w adresie, a tak jak pisałem mix uprawnień jest spory, więc chętnie dodałbym taki dodatkowy element zabezpieczający.

A nie prościej zabezpieczyć to od strony aplikacji ?

Pewnie, że warto, ale wszystkich ewentualności nie przewidzisz. Np. wczoraj odkryłem, że preparując formlarz można do rekordu przypisać osobę z zupełnie innego działu, bo zapomniałem zabezpieczyć powiązanie między rekordami ograniczeniami etc. Przy tak złożonych relacjach - działy, różne uprawnienia, różne akcje i co najgorsze powiązania między różnymi obiektami... łatwo coś pominąć/przeoczyć już na etapie projektowym.

Takie dodatkowe zabezpieczenie jest o tyle fajne, że już preparowanie formularza staje się trudniejsze, bo trafienie w 40 znakowy hash jest praktycznie niemożliwe.

Tu masz ciekawą dyskusję.

http://stackoverflow.com/questions/517579/...in-sql-database

O dzięki - chyba wszystko jasne.

Jeżeli chodzi o aspekt zabezpieczeń... jakiś dodatkowy plus, ale nic szczególnego. Bardziej chodzi o to by ukryć np. dane statystyczne. Przykładowo tutaj na forum łatwo po samych ID-kach wątków wychwycić, że jest ich ćwierć miliona. Jeżeli chodzi o bazę danych to zdecydowanie powinieneś pozostać przy zwykłych numerycznych identyfikatorach. Ten klucz alfanumeryczny możesz wykorzystać jako publiczny identyfikator, ale nie wewnętrzny.

Ale co za tym przemawia? - wg. informacji z podlinkowanej dyskusji wynika, że w przypadku zwykłych tabel nie ma większego problemu, chyba że mówimy o milionach rekordów. W jednej aplikacji faktycznie tak zrobiłem, że miałem id + w osobnym polu generowałem token, którym posługiwałem się w wielu przypadkach, ale było to średnio wygodne, bo trzeba było np. dla każdego obiektu dopisywać metodę wyszukującą po tokenie, niepotrzebnie duplikowane były dane (np. drugi indeks na token, żeby wyszukiwanie szło sprawnie) itp. Wtedy akurat case był z gatunku ukrywania danych, żeby np. w linku nie wyświetlić maila czy id użytkownika, ale już wtedy zaczęło mnie zastanawiać, czy nie lepiej było po prostu hash ustawić jako id, skoro i tak musiał być unikalny.

Indeksy typu hash mają kilka zalet - tak jak wspomniane trochę zwiększają bezpieczeństwo (np. przeciw sql injection, czy wstrzykiwaniu czegoś do formularzy), pozwalają ukryć wrażliwe dane w url, pozwalają no to co wspomniałeś, czyli np. ukryć dane statystyczne (np. numer zamówienia w sklepie internetowym jako losowy ciąg zamiast kolejny numer, aby konkurencja nie wiedziała ile zamówień realizujesz) itp itd. Wszystko to można uzyskać dodatkowymi polami w bazie, tylko czy jest sens.

https://en.wikipedia.org/wiki/Security_through_obscurity

I tak jak mówi Crozin, ma to znaczenie tylko jeśli chodzi o "ukrywanie informacji", a nie jakieś SQL injection czy inne zagrożenia bezpieczeństwa jeśli chodzi o warstwę aplikacji. Dodatkowo przy hashowaniu istnieje pewne prawdopodobieństwo (zależne od wyboru funkcji hashującej) kolizji, więc musi być dodatkowy etap sprawdzania czy już takiego hashu nie ma (na poziomie bazy albo aplikacji).

Narzut na dodatkową kolumnę z takim statystycznie unikalnym alfanumerycznym identyfikatorem jest naprawdę niewielki. Zaś klasyczna kolumna numeryczna ma nieco zalet:
1. Wydajność - nie potrzeba wielomilionowych tabel by to odczuć - wystarczy kilka JOIN-ów i już może to być zauważalne.
2. Lepsze wsparcie ze strony wszelakich narzędzi, szczególnie w przypadku gdy mamy do czynienia z kluczami złożonymi. Niestety często słabo radzą one sobie z niestandardowymi rozwiązaniami.
3. Mniejszy rozmiar danych i gwarancja unikalności - o ile drugi punkt w praktyce nie jest żadnym zmartwieniem o tyle pierwszy już przy przesyle nawet relatywnie niewielkich danych może być odczuwalny.
4. Nie masz co się przejmować "duplikowaniem" danych bo użycie alfanumerycznych, długich ciągów będzie miało dużo większy narzut niż takie "powielenie" danych - w cudzysłowie, bo nie jest to dublowanie danych - id i token mają inne przeznaczenia i wykorzystanie.

@reedemer - zgodzę się, że jako jedyny element zabezpieczający nie ma to sensu, ale jako dodatkowy jak najbardziej.

@crozin i właśnie o takie argumenty mi chodziło - problem w tym, że są one trudno policzalne i jak teraz czytam, to każdy ma tu swoją teorię.

Temat jeszcze do przemyślenia.

Jeśli chodzi o kolizję to polecam zastosowanie UUID które jest unikalne w skali całej bazy.

@Pyton_000: UUID/GUID nigdy nie daje gwarancji unikalności, jednakże prawdopodobieństwo wystąpienia duplikatów jest bardzo małe - na tyle by w większości przypadków zignorować taką możliwość i pozwolić bazie danych wywalić się przy próbie dodania duplikatu (unikalny indeks).

Na tyle małe że można założyć że jest unikalne.

Chyba że wygenerujemy w piz... rekordów w jednej tabeli

Minusem jest to że nie jest to najszybszy sposób generowania i używania