Devloger

Deweloperze, nie nadużywaj ID!

Kategorie: Baza danych · 2 komentarzy

Deweloperze, nie nadużywaj ID!

ID w bazie danych

W tym artykule omówię pewną bardzo ważną kwestię - nadużywania klucza głównego ID.

Otóż wbrew pozorom jest to zła praktyka.

Myślę, że bardzo wiele osób sądzi, że możemy użyć klucza głównego nie tylko do jego pierwotnego przeznaczenia - bez żadnych negatywnych konsekwecji, za to z szeregiem zalet.

Wykorzystać go dodatkowo na inne sposoby i do innych celów... Do niedawna sam tak myślałem... Emotikon uśmiechniętej buźki

Dlaczego?

Ponieważ jest to bardzo wygodne. I bardzo ułatwia pracę. Posługiwanie się tym niesie ze sobą sporo zalet. Przy dotychczasowym wykorzystaniu tego rozwiązania nie widziałem żadnych wad. Teraz widzę.

Posłużę się tutaj przykładem z mojego projektu. Będzie to więc moje własne doświadczenie, sytuacja która dała mi nauczkę.

Pokój

Pokoje w hotelu czy akademiku mają swój numer, prawda? I ten numer się nie powtarza, prawda? Tak więc wykorzystajmy ID pokoju jako jego numer... Tak, zróbmy to! To takie wygodne, przyjemne, oczywiste, po prostu jako że ID jest unikatowe tak jak numer pokoju to tak zrobimy, numer pokoju będzie równy ID pokoju.

Jak w praktyce?

Wszystko super, nie było żadnych problemów, elegancko! Do czasu...

Czasem jest tak, że coś wydaje się bardzo dobre. Wydaje się, bo takie w rzeczywistości nie jest. I to takie nie było. To mi się wydawało. Po prostu nie wiedziałem, nie byłem świadom wad.

Zazwyczaj to co wydaje się bardzo dobre, dopiero okazuje się takie nie być głębiej... głęboko...

I tutaj wadę poznałem na własnej skórze, na własnym doświadczeniu. Nadużycie ID zaprowadziło mnie w bardzo nieprzyjemne miejsce...

Ale o co chodzi?

A teraz mój skomplikowany i głęboki przykład który obnażył wady tego rozwiązania.

Czyli pokój który możemy skasować. Ale chcemy go zachować w ramach historii, on musi istnieć (w tej samej encji). Tak więc posłużymy się usuwaniem miękkim. Lecz nawet po usunięciu go na miękko, kiedy nie będzie liczył się w zapytaniach SQL... To dalej jego ID się liczy... A jako że ID jest równoważne z numerem pokoju... To nawet po takim usunięciu już żaden inny pokój nie będzie mógł mieć jego numeru, mimo że pokój został usunięty... Ajjj... Tu się zaczął tworzyć dość spory problem...

Którego by nie było jeśli numer pokoju byłby przechowywany jako osobna, dedykowana, przeznaczona do tego kolumna... Gdybym nie nadużył ID...

I problem zaistniał

Nie wiem, czy jeszcze inne negatywne konsekwencje z tego nie wynikają. Wydaję mi się że nie. Ale no właśnie, wydaje mi się. Może być inaczej. W każdym razie ten jeden jest wystarczający.

Myślę że to deklasuje zalety tego rozwiązania.

I w prawdziwe nazywając rzeczy po imieniu, tym to właśnie jest - nadużyciem ID. Wykorzystaniem tej liczby do rzeczy do których nie jest przeznaczona. Zła praktyka!

Po prostu nie róbmy tak. Tak nie jest ładnie. ID nie jest do tego przeznaczone. Wszystko ma swoje przeznaczenie i cel. Nie nadużywajmy pewnych rzeczy Emotikon uśmiechniętej buźki.

Wnioski?

Czasami coś się tylko wydaje bardzo dobrym rozwiązaniem. Czasami nim faktycznie jest.

Niestety bywają sytuacje takie jak ta, kiedy dopiero przekonujemy się o tym w praktyce (czasem boleśnie).

Ale nadużywanie ID do celów do których liczba ta nie jest przeznaczona... może prowadzić tak jak u mnie do bardzo negatywnych rezultatów i wielu problemów.

Stąd to moje przesłanie, lekcja oraz rada. Abyś ty nie spotkał się w przyszłości z tego typu problemem Emotikon uśmiechniętej buźki.

Deweloperze, nie nadużywaj ID!

To tyle w dzisiejszym artykule. Myślę że bardzo cenna rada, którą sam bym niesamowicie docenił. Bo do niedawna myślałem zupełnie inaczej.

Ale doświadczenie i praktyka pokazały jak jest naprawdę.

Dziękuję za lekturę, zapraszam do przeczytania innych moich artykułów. Zostaw proszę komentarz i podziel się artykułem jeśli uważasz że jest pomocny Emotikon uśmiechniętej buźki. Bywaj!

Krystian Bogucki

Podobał Ci się ten artykuł?

Jeśli tak, to zarejestruj się aby otrzymywać powiadomienia o nowych artykułach. Nie ujawnię nikomu Twojego adresu!

2 komentarzy... przeczytaj komentarze albo dodaj nowy komentarz


Agafraz

2018-02-15

Szczerze nigdy się nie spotkałem z wykorzystaniem na poważnie ID w celu niesienia w nim jakiejś dodatkowej treści. Właśnie głównie dlatego się tak nie robi bo większość baz danych dla bezpieczeństwa spójności danych nie nadaje tych samych ID w tabeli już nigdy chyba że zrobisz dropa tabeli. Myślę, że nie po to implementuje się mechanizmy takie jak auto_incrementy w silnikach baz danych, aby z tego nie korzystać. W Twoim przypadku z pokojami już lepszym rozwiązaniem byłoby ich nie usuwanie, a dodanie atrybutu typu ENUM z stanem pokoju typu remont/usuniety/wolny/zajety. Kolejną wadą może być trudność w przeglądaniu danych przez analityka danych. Wyobraź sobie, że kluczem jest PESEL. Jeśli w innej tabeli byłby on kluczem obcym to...... to po co ma być połączony tą relacją skoro i tak przetrzymywany jest ten pesel w drugiej tabeli. Doprowadza to do zagadnień redundancji informacji. Również analiza bo pesel jest duży pomiędzy tabelkami jest trudniejsza dla człowieka. Polecam w tym temacie poszukać o postaci normalnej baz danych i ich normalizacji.

Devloger

2018-02-16

Oczywiście, masz rację co do redundacji danych. Jednak warto wspomnieć, że drobna redundacja nie zawsze jest taka zła, a czasem może pomóc. Może działać jak dług technologiczny :). A co do twojej sugestii, to było zastosowane podobne pole. Zastosowałem tam technikę soft_deletes. Ale i tak wykorzystanie ID do celu dodatkowego mnie ukarało. I tutaj jedynym rozwiązaniem byłaby zmiana choćby nieco struktury bazy.