Bocs, nem csak azért írok, mert nem tartom jó ötletnek, hanem mert elégy gyakori tervezési hiba az, hogy ilyen módon oldanak meg valamit.
Igazad van, nagy mennyiségű adat kezelésére való a DB, de azért számoljunk már egy picit. 1000x1000=1M, kétségtelen, hogy nem lesz mindenki "root", de azért nagyságrendnek jó => százezres rekordszám egy szótártáblában. Nekem ez soknak tűnik (arról nem is beszélve, hogy van olyan rendszerem, ahol 6000 user van).
Ugye nem kell ecsetelni, hogy milyen hatékonysággal fog funi egy SELECT/INSERT/UPDATE? Egyetlen rekord feldolgozásakor 1000 oszlopot fog megrágni neked, még akkor is, ha a legporbafingóbb mezei useredről is van szó, akinek van 5 dologhoz joga...
A te elgondolásod szerint minden usernek annyi oszlopa van, ahány rekord a jogosultság táblában (vagy fordítva, tök mindegy, de ez már kapásból rosszul hangzik), ráadásul, az user tábla oszlopai idegen kulcsok a jogosultság táblára, amik lehetnek NULL értékűek is, ha az adott user nem rendelkezik az adott joggal. Szerinted a soronkénti 1000 idegen kulcs leelenőrzése egy INSERT/UPDATE alatt mennyi ideig tart az adatbázisgépnek?
Egyáltalán megengedik a mostani adatbáziskezelők, hogy ennyi oszlopod legyen?
Ja, és sajnálom majd azt a db admint akinek ezt az adatbázist kell majd karbantartnia. :-D Egyáltalán megnézném azt a db toolt, aminek kifér a képernyőjére 1000 oszlop.... :-)
De ez igazából az elv a lényeg. Ha a struktúra futásidejű megváltoztatása nélkül nem lehet megoldani egy problémát, akkor az adatbázisterved rossz és kész. Ezen szerintem nincs mit vitatkozni. Ha gyenge a teljesítmény, akkor optimalizálni kell, de annak nem ez a módja (hanem pl. megfelelő indexek, query-k stb.).
A másik gond, hogy az, hogy a "user" nevű entitásnak milyen "jogosultság" entitásokhoz van köze, az ebben az esetben egy kapcsolat, nem pedig attribútum. Ez hatalmas különbség, de ennek ellenére hogy sokan mégis így terveznek adatbázist és igazából ez a bajom... :-)
Ennyi erővel azt is megtehetném, hogy mondjuk egy fódum adatmodelljében minden felhasználónak annyi oszlopa lenne, ahány témához hozzászólt... :-)
Persze, tudom, vannak adatbázisok amik milliós rekordszámokkal számolnak, de ott az átlagszerver nem holmi desktop pcből van összekalapálva, magyar valóságban meg de.
Ha ennyi usered és ennyi jogosultságod van mert mindenképpen mindent customizálni akarsz, akkor ezt az adatmennyiséget nem fogod megúszni. Akkor viszont az 1000 oszlopos megoldás még sokkal rosszabb hatékonyságot eredményez ha az átlag usernek viszonylag kevés jogosultsága van. A megvalósítás nehézségeit meg ne is nézzük...
(Azt csak mellékesen mondom, hogy nem tudom, hogy mi indokolja az ilyen mértékű konfigurálhatóságot, mert ehhez már komoly felkészültség kell az userek részéről is, hogy minden jogról mindenki tudja, hogy mihez is kell...).
...de azért számoljunk már egy picit...
Számoljunk:
Hash tábla index esetén egyetlen rekord címének kiszámítása optimális esetben egyetlen hash bejegyzés beolvasását igényli, függetlenül a rekordok számától. Ha ütközés van, akkor persze valamivel többet, de általában ez igaz. Ha valahogy darabolva van a hash, akkor lehet még egy-két művelet.
B+ fa index esetén a lemezműveletek száma m alapú logaritmus arányban nő a tábla hosszával, m a fa egy csomópontjában tárolt kulcsok száma (1000..4000). Ez egy egymilliós tábla esetén kb. 3. Ebből nyugodtan le lehet vonni egyet, mert a fa gyökerét memóriában szokás tárolni, tehát azt már nem kell beolvasni.
De tudod mit, szerintem próbáld ki. Csinálj egy táblát, két oszoppal (elsődleges kulcs, meg valami random érték), töltds fel 1M rekorddal és ajd ki egy selectet egy konkrét kulcsértékre. Szerintem meg fogsz lepődni... :-)
Mégegyszer bocs, de ez annyira durva volt ez az 1000 oszlop.... :-) Ilyet nem tervezünk adatbázisba....
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "