Tiszteletem!
A bonyolult (és talán nem túl precíz) cím után megfogalmaznám az alapproblémámat, amiben a segítségetek kérném.
Egy agyonkonfigurálható honlap jogosultságkezelést kellene SQL alapon megvalósítanom. Miként lenne a legjobb tárolni a funkció jogosultság - user kapcsolatot? (tételezzünk fel 1000 funkciót és 1000 usert)
Bízom benne, hogy valakinek triviális a megoldás és okít egy picit. :)
Az én ötleteim/elképzeléseim:
1- simán 2D mátrixként tárolni, durvának hangzik, mert mégiscsak 1000 mező széles tábla...arról nem is beszélve, hogy új user felvitele esetén az oszlop hozzáadás nem egy szép megoldás.
2- 1000 file és 1000 user esetén nem tűnik túl jó ötletnek mindenféle párosítását 1 rekordként tárolni, mert nemkicsit lesz hosszú a tábla.
3- 1 mezőben, stringként összefűzve tárolom, hogy mikhez férhet hozzá a user...hátránya, hogy funkciótörlés esetén nem olyan egyszerű törölni a minden stringből amiben szerepel
Mondjuk lehet ugye usergroupokat betenni, ami a méretet csökkenti a párosítások kombináció száma miatt, de a vámon elvesztem ezt, hiszen a group-user párosítást is meg kell csinálnom.
A 2. variáns felé hajlok, mert mégiscsak arra lehet jó SQLeket írni...de a várható hosszúsága némi aggodalommal tölt el.
Előre is kösznöm!
- 2251 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
thx, megkukkantom
- A hozzászóláshoz be kell jelentkezni
[off]
Amit agyon lehet konfigurálni, azt még nem feltétlenül kell, depláne nem szabad.
Gyanús nekem ez az 1000 user/1000 jogosultság...
Kicsit nehéz lehet áttekinteni, hogy kinek mit szabad.
Az általam eddig látott legvadabb (öreg, szétfejlesztett, koncepciótlan, betegül adminisztrált) alkalmazásban sem volt 100-nál sokkal több szerepkör, amibe a felhasználókat be lehetett sorolni. Egy átlag alkalmazás meg 1-2 tucat szerepkörrel jól működik.
Szóval szerintem felhasználó -> szerepkör -> funkció -> elemi jog.
Ebből a funkció szint elhagyható, ha elég egyszerű az alkalmazás.
mrceeka
[/off]
- A hozzászóláshoz be kell jelentkezni
Szép volna, ha ez így működne. A tapasztalatom az, hogy nincs olyan hülye elképzelés amit a megrendelő ki ne találna...s lehetőleg hetente ne gondolná meg magát.
Itt ne szerepkörökben gondolkodj az már a második lépcső (nyilván én sem fogom userenként kiosztani az x jogosultságot, hanem groupokba rendezem őket), de kivételek mindig vannak, sőt!
Ha az ideális állapotot vesszük, akkor egy szervezetnek van SZMSZ-e, amit qrva könnyű lemodellezni és mindenki boldog, ám a magyar valóságban az csak a papír...néha a titkárnőkre szabadítana egy csomó hálátlan főnöki teendőt ésatöbbi, persze úgy, hogy csak adott feladatot tudjon megcsinálni, máshol ne kotorászhasson. Ergo a szerepkörökön túl mindenre kell tudnom kivételt csinálni, ami ugye nem más mint az 1 egyén, 1 szerepkör szituáció. Amit persze franc akar adminisztrálni, tehát felviszem az embereket a nagykönyv szerinti szerepkörökbe/groupokba majd szépen minden Gizikének adok plusz jogköröket. De ehhez funkciónként kell eltárolnom a történetet.
Legalábbis én így képzelem a történetet. :)
u.i.: attól a harcias állásponttól szakadjunk el, hogy körém építik a céget, mert akkor reorganizációs igazgatónak hívnának. Ráadásul mindig lesz valaki aki lehülyéz, megcsinálja bedrótozva az aktuális pillanatra (én megkapom a fekete levest, hogy "bezzeg ő"), aztán amikor hosszabbtávon a bedrótozás miatt szívunk akkor meg lehet fókázni.
Meg vegyük hozzá azt is, hogy a funkciók is állandóan bővülnek, mert az elején ŐK írták le a követelményeket...aztán menet közben kozmetikázzák a szűklátókörűségüket.
- A hozzászóláshoz be kell jelentkezni
Még annyit, hogy amíg a megrendelőnél nincsenek rendesen megszervezve a dolgok, addig rendes szoftvert sem lehet írni. A szervezés külön része lenne egy ilyen projektnek, amit szeretnek a cégek megspórolni, mondván az túl sok pénzbe és energiába kerülne, de azt persze nem veszik figyelembe, hogy mit nyernének vele (de valószínűleg pénzük sincs rá).
Viszont amíg káosz van odaát, addig nem fogsz rendes szoftvert csinálni és ezen semmilyen agyonáltalánosított megoldás nem fog segíteni... Mindig lesz egy "nagyon fontos" és "nagyon sürgős" igény ami tegnapra kell és amire pont nem jó az eddigi rendszer. Nem elkeseríteni akarlak, csak ismerem milyen az ilyen.... :-(
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
Kedves Wlaszi!
Előre is elnézésedet kérem a kritikáért, de mielőtt nekifogsz adatbázissal programozni/feladatot megoldani, szerintem el kellene olvasnod egy-két könyvet az adatbázistervezésről, mert amiket itt felvetettél, hát, hogy is mondjam finoman, szóval egy kicsit sokat kell még olvasnod ehhez, ha ilyen kérdések merülnek fel....
Ajánlom figyelmedbe: HALASSY Béla - Az adatbázistervezés alapjai és titkai : Avagy az út az adattól az adatbázison át az információig - ISBN: 963 8287 012.
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
De hogy még építőleg szóljak a dologhoz (mert egyszerűen nem tudom szó nélkül megállni, annyira bántanak ezeke a felvetések):
1- simán 2D mátrixként tárolni, durvának hangzik, mert mégiscsak 1000 mező széles tábla...arról nem is beszélve, hogy új user felvitele esetén az oszlop hozzáadás nem egy szép megoldás.
Na, figyi: ez nem "nem egy szép" megoldás, hanem a lehető LEGROSSZABB!!!! Ennél már csak az lenne rosszabb, ha minden userhez létrehoznál egy táblát, vagy valami hasonót akarnál....
Válasszuk szét az adatbázis stuktúráját és a tartalmát! A struktúrába bele tartozik, hogy milyen táblák vannak, egy táblában hány oszlop van, azok milyenek, stb. A struktúra a normál használat közben NEM változik. Sőt, nem is változhat mivel egy jólnevelt rendszerben ehhez nem is rendelkezel jogosultsággal (legalábbis nem kéne rendelkezned). Te max. a tartalmát tudod megváltoztatni.
2- 1000 file és 1000 user esetén nem tűnik túl jó ötletnek mindenféle párosítását 1 rekordként tárolni, mert nemkicsit lesz hosszú a tábla.
Miért is nem? Egy adatbáziskezelő nem arra van (többek között), hogy akár sokszázezres/milliós rekordot tartalmazó "óriás" táblából keressen vissza hatékonyan? Egy jó index (B-fa, hash) egyetlen rekordot max 1-2 fizikai lemezművelettel megtalál, már ha épp valami miatt nincs a memóriában a keresett sor.... Nyilván összetetteb lekérdezéseknél ez kicsit tovább tart, de az sem sokkal....
Arról nem is beszélve, hogy nem minden usernek van mindenhez joga, tehát nem kell kapcsolat minden user és minden jogosultság közé....
3- 1 mezőben, stringként összefűzve tárolom, hogy mikhez férhet hozzá a user...hátránya, hogy funkciótörlés esetén nem olyan egyszerű törölni a minden stringből amiben szerepel
JAJ NE! :-) Ezzel gyakorlatilag bitvadászatba kezdesz. Ahelyett, hogy az egészet elintéznéd egyetlen jól irányzott "DELETE_ FROM" utasítással, elkezdesz mindenféle stringműveletekkel bíbelődni??? Na, az ilyenekből szoktak születni a tipikus bugbánya, karbantarthatatlan és átláthatatlan programok.... :-)
Szeritem ne akarj valamire külön megoldást kieszelni, amire már van egy egyszerű - és jól működő - módszer....
De mindenképpen, először készülj fel a témából egy kicsit, ha már ekkora rendszerbe vágod a fejszédet...
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
:-) off: SQL injection protection rulez: amikor az előbbi postomban a "delete f..." parancsot tartalmazó szöveget az aláhúzás karakter nélkül akartam elküldeni, kaptam egy szép FORBIDDEN hibaüzenetet az orcámba...
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
mod_security vagy vmi ilyesmi a ludas.
trey mar tobbszor emlitette
Tyrael
- A hozzászóláshoz be kell jelentkezni
Kedves Ballage!
A könyv olvasáson túl vagyok már pár éve, persze ez nem jelenti azt, hogy nem lenne még mit, de azért köszönöm az ajánlást. :)
Szerinted ez triviális, szerintem annyira nem. Az adatbázisok legtöbbjénél a tulajdonságok száma (táblaszélesség) előre definiálható és többnyire fix de az esetemben nem...avagy nagyon hosszú lesz, amiről viszont tudjuk, hogy lassít.
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). 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.
Amennyiben a felsorolt variációim miatt borult nálad ki a bili, akkor sorry, de a teljes képhez hozzá tartoznak, főként azért mert az általad jó megoldásnak tekintett verziót is _szerintem_ nem optimálisnak (azaz hibásnak) vettem, tehát akkor már a többi "nem optimálisnak" is ott a helye.
Abban igazad van, hogy lehetséges, hogy a spanyol viaszt akarom feltalálni, törődjek bele, hogy ha hosszú lesz, hosszú lesz...de szerintem mindig kell keresni a jobbat. Filóztam rajta, nem jöttem rá, gondoltam hátha valaki igen.
A thread folytatásodra nem reagálnék klön, mert bár reméltem, hogy kitűnik a nyitópostból, hogy tudom miért nem jó gondolatok úgy tűnik nem hangsúlyoztam ki eléggé. Másszóval igen, úgy van ahogy írod :)
- A hozzászóláshoz be kell jelentkezni
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! "
- A hozzászóláshoz be kell jelentkezni
Mégegyszer bocs, de ez annyira durva volt ez az 1000 oszlop.... :-) Ilyet nem tervezünk adatbázisba....
Tudom, hogy az, de az elvileg nem lehetséges és a gyakorlatilag nem csinálok között van különbség. Tehát a felsorolásba szerintem beletartozott. Szerinted leírni is hiba volt. evvan :)
Véleményed szerint, ha nem látom azt a hibát amit itt ecsetelsz, akkor egyáltalán írtam volna egy fórumba? Tapasztalatom szerint az "ilyenek" nekiállnak kapásból megvalósítani. .)
Ne ragozzuk.
A felvetés jogos...mit dilemmázom itt, mérjem meg, kiderül :) Csak kérdezni egyszerűbbnek tünt :)
- A hozzászóláshoz be kell jelentkezni
Az alaptézised hibás. Mindig a konkrét probléma dönti el, hogyan lehet kezelni dolgokat.
A megváltoztatható tulajdonságokat kategóriákba kell sorolni (biztos vannak olyan tulajdonságok, melyek egy kalap alá vehetők), így jelentősen lecsökken a jogosultségok száma. Pl. nem tudok olyan alkalmazást elképzelni, ahol teszemfel a szöveg színén van jogom változtatni, a méretén meg nem. Ha kategórizálunk, akkor lehet azt mondani, hogy a szövegstílus hozzáférési joga.
Ezenfelül nem tartom túl yó ötletnek ha a userek a megjelenítést abszolute szét tudják konfigurálni, mert nem lesz... hogy mondjam.. arculata az oldalnak. Semmi nem fogja mutatni, hogy ez a te oldalad. Lehet persze színtémákat (skin, smink, nevezd aminek akarod) létrehozni, lehet mozgathtó boxokat csinálni, meg ilyesmi, de ennél mélyebb konfigurálás már szvsz a baromság határát súrolja. Hogy miért fontos ez? Mert ha ezt megérted, rájössz, hogy nagyon kevés jogosultság van, amit ki kell osztani.
Magának a projektnek az alapjait gondold ki előbb, és utána tervezz alá adatbázist. Ha nem vagy teljesen tisztába mit akarsz, az alá felesleges adatbázis.
- A hozzászóláshoz be kell jelentkezni
A lényeg, hogy funkciószinten tudjam szabályozni, mert sajnos számomra bármennyire is ésszerű valamiket kizárólag együtt kezelni, szinte biztos, hogy valakinek kell valami kivétel...részemről most untam meg ezt a szopófaktort és próbálnék valami olyan új alapot létrehozni, amivel a T. vezetők a cégeiket boldogítják, ellenben engem max 3 másodpercre. Szemben az eddigi órákkal amikor gyurmázni kellett a kódban, hogy létezhessen kivétel annál az 1 funkciónál.
Egyébként itt nem arról van szó, hogy a userek szabhassák testre az oldalt, hanem arról hogy egy elég heterogén összetételű bagázst kell egyetlen felületről kiszolgálni. Tehát csakis azt lássák ami az ő személyüket érintheti. Egyfelől ez, de másfelől meg ott van az, hogy ki mit állíthat, gyakorlatilag kismillió kis adminisztrátorom van. Mivel mást és mást látnak, más és más állítási lehetőségeik vannak (ilyen adatok, olyan adatok), Össze nem köthetem a két dolgot, mert lehetséges, hogy valaki csak láthatja az adatot, valaki hozzáadhat, valaki törölhet, valaki meg már csak módosíthat. Ráadásul bármikor benyöghet nekem valaki olyat, hogy akkor ez most legyen egészen másként, vagy xy tehessen meg most valamit mert sürgős, de kizárólag azt..aztán majd 2 hét múlva vissza minden.
A project amúgy nagyon ki van találva, csak ezt a ki-mit csinálhat dolgot kell megoldanom.
- A hozzászóláshoz be kell jelentkezni
Hát, ha erre nem jó egy kapcsolótáblás megoldás, akkor nem tudom mi kell.... :-)
Szerintem sokkal több szívás lekezelni 1000 oszlopot... De mind1.
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
szakadj már el ettől a példától! :) Leírtam mert elvi lehetőség van rá, kapásból ki is zártam. Reméltem, hogy valaki mond majd valami 4. variációt. Úgy tűnik nem lehet. A kérdés már csak az, hogy mennyi az annyi? Mindjárt generálok magamnak egy táblát aztán ha minden igaz akkor beigazolódik az amit mond itt mindenki, hogy lópikula ez a méret.
- A hozzászóláshoz be kell jelentkezni
Nézd, ha ilyen a helyzet, én mindenképp megpróbáltam volna már a projekt elején beindítani a PR gépet a megrendelő felé, hogy ez miért nem yó ötlet. Ha van valamennyi tapasztalatod a weboldalkészítés témakörében (hozzászólásaidból azt látom, hogy elég sok),nyilván magad is tisztában vagy a dolog ordító kilátástalanságával és értelmetlenségével.
Heterogén bagázst kell összefogni... hát nem is tudom. Mindenképp érdemes lett volna elgondolkodni azon, hogy a kliensek (userek) is alkalmazkodjanak valamenniyre. Nem hiszem, hogy ha ügyesen van előadva, a megrendelő cég torkán le nem lehetett volna tolni ilyesmit. Ez a "demostazonnalsürgősen" célokra vannak a különböző site-adminok, akiket szépen megkérve lehet dolgokat csinálni.
Ha az oldal egyes elemeit kell testre szabni, akkor sem hiszem, hogy ne lehetne az usereket csoportokba foglalni (nem csak a tulajdonságokat lehet), amivel yóval egyszerűsödik a kérdés. Azaz, adott mondjuk a pénzügyesek csoportja, ami eztmegezt láthatja, aztmegazt még szerkesztheti is, de emezt meg amazt nem láthatja. Akár a kettő kombináűlásával is lehet dolgozni.
Hidd el, mindenképp érdemes csoportosítani/egyszerűsíteni, mert egy idő után sem te, sem a főfőfő adminisztrátor nem fogja tudni áttekinteni, hogy ki mit tehet és mit nem. És ebből csak fejetlenség születik, meg minden egyéb más probléma.
Ha jobban belegondolsz (nem akarok mindent kifejteni, gondolkozz egyedül is), akkor mind a megrendelő, mind a saját yól felfogott érdeked azt diktálja, hogy egyszerűsítsd a rendszert amig lehet, mert előbb-utóbb ez így nem rendszer lesz, hanem egy káosz, amit valaha rendszernek becéztek.
- A hozzászóláshoz be kell jelentkezni
Elmondom mi nálam ilyenkor a default történet:
A megrendelők mindent azonnal és lehetőleg "ingyen" akarnak. Én elmondom, hogy én megcsinálhatom így, de az hosszútávon ráfizetéses lesz (mert ugye gányolásról beszélünk). 99%, hogy az lesz a válasz, hogy "nem baj, legyen így". Aztán persze amikor a taknyolás miatt már nem megy a tegnapra határidő, mert már nagyon megerőszakoltuk a rendszert, akkor jönne a "fizess!" felszólítás....amire persze elkezd hüledezni mindenki, hogy most miért ennyi?...pedig az ember előre szólt.
Ha én ezt a variációt nem ajánlom fel, mert ugye szakmailag nem megengedhető, akkor jön majd valaki, aki az én rendbentartott kódomat hajlandó eltaknyolni, és góré meg azt veszi észre, hogy "lámlám, ő megcsinálná, te meg nem".
Tehát lehet érvelni, de ez valahogy baromira nincs tolerálva a piacon. (legalábbis én így tapasztalom).
Volt olyan tapasztalatom, hogy bedolgozónak hívtak és a megbeszélésből hirtelen kódolás lett...úgy simán tervezés nélkül, ad hoc. El lehet képzelni, hogy mekkora barkács lett, úgy on the fly hoztuk létre az adatbázist...alig volt redundancia benne. És ebben az a szörnyű, hogy ezt nem a nullatudású megrendelő szervezte, hanem a beszállító informatikai cég! Szóval akkor most kiről gondolja az ember azt, hogy ilyen szakmai érvekkel befolyásolható, ha már a "kollegák sem".
Fentebb valahol írtam, hogy lesz csoportosítás. Sőt, hogy pontosítsak: jelenleg csak csoportokat használok (mint a legtöbb helyen), de a kivételekhez muszáj lebontanom funkciókra. De nem ettem meszet, hogy 1 usernek kiscsillió funkciót állítsak be...kézzel csak a kivételeket akarom állítani és erre kerestem a megfelelő szerkezetet, de úgy látom 1 közül lehet választanom ami eddig is volt... :)
- A hozzászóláshoz be kell jelentkezni
"El lehet képzelni, hogy mekkora barkács lett, úgy on the fly hoztuk létre az adatbázist...alig volt redundancia benne."
Ez érdekes. Én örülök, ha nincsen redundancia az adatbázisomban. Többek között ezért találták fel a normalizációt is...
- A hozzászóláshoz be kell jelentkezni
ez irónia volt...normalizáláshoz meg tervezni kell. Mert úgy az nem működik, hogy véletlen látok egy fv paramétert...és akkor én kezdek el tanakodni azon, hogy mégis kéne valami ilyesmit létrehozni az adatbázisban mert aki kódolt, az ezzel nem foglalkozott...stb. Vagy 3 kóder 3 helyre tolt be egy olyan paramétert amire éppen szüksége volt, sz*rtak megnézni/megkrdezni, hogy valaki csinált- már iyet. Így Te nem fogsz normalizálni. :(
- A hozzászóláshoz be kell jelentkezni
Ha én ezt a variációt nem ajánlom fel, mert ugye szakmailag nem megengedhető, akkor jön majd valaki, aki az én rendbentartott kódomat hajlandó eltaknyolni, és góré meg azt veszi észre, hogy "lámlám, ő megcsinálná, te meg nem".
Tehát lehet érvelni, de ez valahogy baromira nincs tolerálva a piacon. (legalábbis én így tapasztalom).
Igen, sajnos nem ritka az ilyen. A kérdés mindig az, hogy az ember mennyiért vállal be egy ilyen szerepet, ha egyáltalán bevállalja. Elég sok programozó van, aki bevállalja a gányolást is ha kell. A főnök meg nyilván mindig a legkisebb ellenállás felé megy. Napi túlélési stratégia.... :-/
De az ilyesmi azért a megrendelőről is elmond valamit. Valószínűleg csak az összeget nézi a papíron, ami a részéről elég szűk látókörre vall. Pláne, ha nem először fordul elő, hogy nincs arányban az aktuális feladat és az összeg....
Ez kicsit a lószar meg a veréb esete. Amíg van olyan vevő, akit csak a minél alacsonyabb ár érdekel, addig lesznek gányprogramozók is.... Aztán persze megnézheti, hogy mit kap a pénzéért, de ez már egy másik történet....
"-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
Alap...
Jogosultsag tabla,
User tabla
Kapcsolo tabla (az azonositok alapjan)
Attila
- A hozzászóláshoz be kell jelentkezni
bővebben lásd feljebb.
röviden: engem aggaszt a túl hosszú szótártábla (~kapcsolótábla). Szerinted ez nem problémás részlet?
- A hozzászóláshoz be kell jelentkezni
Túl hosszú alatt azt érted, hogy (szerinted) sok rekord van az adattáblában? De hát a lekérdezés sebessége nem függ* a teljes táblában tárolt adatok mennyiségétől!
(* pár százmillió rekord alatt és rendes adatbáziskezelő esetén)
- A hozzászóláshoz be kell jelentkezni
Milyen DB-ről van szó? A felvezetésed alapján gondolom, hogy nem egy Oracle. :-)
Egyébként az adatbáziskezelők tényleg nagytömegű adathalmaz manipulálására készültek, tehát nem kell megijedni néhány százezer sortól.
- A hozzászóláshoz be kell jelentkezni
mysql (flamet kéretik mellőzni, oracle fetisisztákat külön megkérem erre), a legtöbb helyen amivel kapcsolatban vagyok, ezt használnak.
Egyébiránt eddig nekem mindent sikerült ezres rekordszámmal megoldanom (nem volt többre szükség) szóval ezért érzem nagy falatnak a százezreket...főleg, hogy nem highend vasak mennek alattuk.
- A hozzászóláshoz be kell jelentkezni
Amelyik adatbáziskezelő nem képes százezres táblákat normálisan kezelni (feltéve, hogy megfelelően fel vannak indexelve), az szerintem csak játékszer, nem igazi adatbáziskezelő. Mindenféle gyártótól függetlenül....
-------------------------------------------------
" - Amerikanische Infanterie! Angriff! Angriff! "
- A hozzászóláshoz be kell jelentkezni
Ebben a konstellációban jóval nagyobb problémának tartom a jogosultságok karbantartását, mint az adatbázis teljesítményét.
- A hozzászóláshoz be kell jelentkezni
tobbtizmillios logtablak errefele is vannak mysql-en, amig nem akarok rendezni vagy group by-olni, addig nincs vele problema, "szinte" azonnal jonnek az eredmenyek.
persze megfeleloen normalizalva, es indexelve vannak a tablak.
Tyrael
- A hozzászóláshoz be kell jelentkezni
Hátha megnyugtat: kezeltem már többtízmilliós táblákat postgresql alatt, 32 hosszú string id oszlopokkal, gond nélkül (asztali pc). Ha a mysql nem bírja, válts postgresre...
- A hozzászóláshoz be kell jelentkezni
igen, megnyugtat. Thx!
- A hozzászóláshoz be kell jelentkezni
Csodálkozom, hogy senki nem javasolta még az LDAP-ot.
Egyébként a kapcsolótáblás megoldás jön csuklóból.
Ha "bonyolítani" akarod, akkor meg role-okkal meg lehet spékelni, ahol is a role nak van jogosultsága, a usernek meg role-ja.
És persze esetleg a usernek is lehet plusz jogosultsága.
Javaslom megtekinteni pl a drupal jogosultságkezelését.
További gyanúm (bár ne lenne igaz) hogy ismét feltalálódik valami spanyolviasz-szerű, ami már létezik a "piacon", vagyis letölthető. Pl. a drupal... :)
Egyébként pl. mysql, postgresql-nek sem gond a százmilliós tábla, láttam már nem egyet.
Kicsit tuningolni érdemes, az igaz.
--
Gabriel Akos
- A hozzászóláshoz be kell jelentkezni
Javaslom megtekinteni pl a drupal jogosultságkezelését.
További gyanúm (bár ne lenne igaz) hogy ismét feltalálódik valami spanyolviasz-szerű, ami már létezik a "piacon", vagyis letölthető. Pl. a drupal... :)
Megteszem, bár a legtöbb portalmotorban egy elég szűk jogosultságkör van (pl modulszintű), nekem ennél finomabb kell.
Bizonyára van már ilyen, ha így nézzük a drupal is csak egy klón :) Hovatovább minek irogat valaki linux progikat... :)
Másfelől meg nekem az az álláspontom, hogy sokkal inkább ki vagyok téve a scripteknek mint célzott cracker támadásnak.
- A hozzászóláshoz be kell jelentkezni
És nem is egy labor kisérlet elfajult terméke, hanem egy nagyon jól átgondolt, de korántsem tökéletes, jól felépített és igen rugalmas tartalom kezelő, a társairól ez nem igen mondható el.
Sajnos a valóban nem derül ki azonnal a drupal ereje, egy kis feature lista olvasgatásból. Drupálnál testreszabhatóbb, "agyon konfigurálahtóbb" rendszerrel mg nem találkoztam. Ha megnézed http://drupal.org/project/Modules/category/74 akkor kedvedre kutatkodhatsz a hozzáférési módok között, melyek akár egymással is kombinálhatók.
A drupalban, egyébbként sem modulokra van jogosultság hanem funkciókra.
- A hozzászóláshoz be kell jelentkezni
Szerintem is kapcsolótáblás megoldás. Azt írtad, hogy inkább csak kivételek kezelésére kell, ami a csoportok jogait egészíti ki/szűkíti. Ha így nézed, csak azokat a jogokat kell lekezelni külön, ahol van valami speciális kivétel, ami meg már messze nem user*jogok száma, hanem kivételezett userek * kivételek, ami gondolom nagyságrendekkel kissebb.
- A hozzászóláshoz be kell jelentkezni