Nem hülyeség az, hogy egy adatbázis táblába mindig rak valaki egy auto incrementes id-t?

Ha most az adatbázis optimalizáláson vitatkoztok, akkor közlöm: ez nem az.

Ill az: már a rendszer létrehozásakor illene megtervezni ugye, hogy az adatbázisok milyen egyedi azonosítókulcson kapcsolódnak.

És szerintem erre pont nem egy autoincrements mező a legalkalmasabb

Van az elmélet, meg van a gyakorlat. Elméletileg egy táblánál ha lehet a ténylegesen benne tárolt adatokból elsődleges kulcsjelölteket kijelölni, akkor abból kellene választani. Mondjuk egy usert jól be tud azonosítani az email címe. Oké, legyen ez az elsődleges kulcs. Mi a probléma ezzel?

Pl. az, hogy idővel lehet, hogy a rendszernek le kell tudnia kezelni, hogy az email címét valaki megváltoztatja, viszont ehhez át kell írni az összes userre való hivatkozást. De az is lehet, hogy ennek ellenére meg kellene őrizni, hogy mondjuk egy fórumon a változtatás előtt milyen email címmel futott a felhasználó. Opsz… Lehet átalakítani az adatbázist.

Lehet, hogy az elsődleges kulcs mondjuk egy hosszabb szöveg – pl. itt az email cím –, de mindenhol erre hivatkozni, minden az user táblához kapcsolódó táblában egy 4 bájtos szám helyett egy 254 karakteres idegen kulcsot használni, nem biztos, hogy erőforrás és tárhely kímélő megoldás.

Vagy pl. lehet, hogy a felhasználót törölni kell a rendszerből, de a hozzá tartozó adatok nem törlődhetnek. Oké, az user táblába felveszünk egy „active” mezőt, és megoldottuk a problémát. Csakhogy lehet, hogy az adott email cím domainje időközben máshoz kerül, aki szeretne regisztrálni a weboldalra, amit az adatbázisod kiszolgált. Megint probléma, mert van két ténylegesen különböző user, de az elődleges kulcsuk ugyanaz lenne.

Néha a legjobb elődleges kulcs összetett. Ott sem könnyíti meg a dolgodat, ha minden összetett lekérdezésnél nem egy, hanem két-három mezőt kell összekapcsolni. Lehet, hogy idővel bejön még egy adat, ami alapján meg kellene különböztetni a tábla különböző rekordjait. Ott nem elég még egy mezőt felvenni, és hozzáadni az elsődleges kulcshoz, hanem minden kapcsolódó táblában fel kell venni, minden összetett lekérdezést át kell írni.

Az egyszerű kulcs is okozhat problémát. Mondjuk egy usert a személyi számával azonosítasz. Az hivatalból egyedi, tehát nagy baj nem lehet. Remek. Csak aztán jön egy törvény, ami eltörli a személyi számot, mondván, hogy adatvédelmi szempontból aggályos, te meg választhatsz új elsődleges kulcsot – pl. adószámot –, és darálhatod át a teljes adatbázist. Oké, viszed tovább az adatbázist az adószámmal, mint elsődleges kulccsal. De úgy alakul, hogy bár nagyon nem terveztétek az elején, mégis külföldi felhasználókat is nyilván kell tartani. Megint lehet új elsődleges kulcsot keresni, módosítani minden kapcsolódó táblát, átdarálni minden erre hivatkozó adatot, mert ugyan van pl. EU-s adószám, csak az már nem 9 karakterből áll, így nem csak azt a táblát kell módosítani, amiben eddig egy CHAR(9) volt az elsődleges kulcs, hanem minden olyan táblát, ami az user azonosítójára hivatkozik.

Itt előfordulhat olyan probléma is, hogy egy adott adatbáziskezelőben egy megváltozott hosszúságú kulcs már túl hosszú lenne, és bár elvi szinten jó elsődleges kulcs lenne az adott összetett kulcs, a gyakorlatban mégsem tudod használni az adott adatbáziskezelő kulcsok hosszára vonatkozó limitje miatt.

Az autoinc azonosítóval nagyon nagy bakot nem lehet lőni. Nem a legoptimálisabb, esetenként lehetne optimálisabb, ha nem egy autoinc érték lenne az elsődleges kulcs. De nagyon nagy veszteséggel sem jár. Egy extra 4-8 bájtos adat elfér, és az elsődleges kulcsod függetlenné válik attól, hogy idővel milyen extra változások jönnek, milyen extra igények jelennek meg a szoftver működésében. Ha a meglévő adatbázisszerkezet struktúrája nem változik gyökeresen, akkor minden ilyen jellegű probléma „lokális” marad, csak egy adott táblát érint, minden további fejlesztés, új táblák, új kapcsolatok függetlenek tudnak maradni a már meglévő adatbázis szerkezettől, nem kell a már meglévő adatbázist újrastrukturálni, több táblában módosítani az adatokat az elsődleges kulcs kényszerű megváltozása miatt, hiszen az elsődleges kulcsod mindezektől független, nem kötődik semmilyen valódi, jelentéssel bíró adathoz.

Tehát az elméletben nem helyes, ha létrehozunk egy extra elsődleges kulcsot, holott az adattáblában vannak elsődleges kulcsjelöltek. De a gyakorlatban, az időbeliséget, a külső és belső változásokat figyelembe véve mégsem ördögtől való dolog.

Kedves kérdező ...

A 8# válaszomban bemásoltam egy normális stackoverflows választ, amit elmondja, hogy mért érdemes ezt használni?

Ez nem számít érvelésnek?

A 11#es kérdező meg a véleményét írta le. Semmivel sem támasztotta alá.

"szerintem erre pont nem egy autoincrements mező a legalkalmasabb"