Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Indeks alfanumeryczny a wydajność
athabus
post
Post #1





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
Crozin
post
Post #2





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post

Posty w temacie


Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 29.12.2025 - 16:54