Az üzleti igény egy olyan adatbázis struktúra létrehozása, amelyben az előre definiált táblák adatai mellé a kusztomerek saját maguk is fel tudnak venni plusz adatokat, anélkül, hogy ehhez az adatbázistáblákat és az alkalmazást módosítani kellene. Sajnos nem csak letárolják ezeket, de még keresni is akarnak egyesekre. Azaz egyfajta open schemat kellene megvalósítani. Erre jó lehet az Entity-Attribute-Value megoldás, de úton-útfélen gonosznak van kinevezve. Értem én, hogy szar belőle lekérdezni, marha nagy lehet, ha egyszerűen csinálják meg nem típusos (én minden típushoz akarok egy oszlopot létrehozni), de milyen használható alternatíva van vele szemben?
Olvastam a serialized blobot, pl. egy xml oszlopba rakjuk a plusz dolgokat. Elvileg lehet xqueryzni, meg indexelni, de érzésre ez se egyszerű, se gyors nem lesz.
A sparse colum esetén séma módosítással jár az új adat definíciója. Ez egyrészt nem tetszik secu okokból (alter table kell hozzá), másrészt elég gáz szervizelni az alkalmazást, ha 50 ügyfél saját oszlopokkal bővítheti a tábláinkat.
Szóval, mi a jó a feladatra? Nekem még mindig az EAV tűnik a legkezelhetőbbnek.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
9 COMMENTS
Az adatbázis struktúra adatbázis-struktúra, viszont ez nagyon pojénosra sikeredett: … séma módosítással jár …
Én meg a barátnőmmel járok :)
Az EAV-val tényleg az a probléma, hogy az egyszerű lekérdezések bonyolultak vele, a bonyolultak meg k. bonyolultak.
Be lehet vetni mondjuk egy Lucene-t, de akkor meg már bonyolultságban vagy ott, mint az XML-nél.
EAV mellet.
“Rendes” táblákban nem lehet mert nem rugalmas (az ügyfél felé). (De ha meg is csinálod, az üzemeltetés először furcsán fog nézni, aztán üldözni és ütlegelni kezd.) Az XML… erre pont ennyit tudok mondani: háááát.
Akkor lehet EAV-zni, ha az ügyfél elfogadja, hogy egyszerűen kereshet benne, de nem lesz sum tól fölfelé semmi (értelemszerűen, nem normalizált tárolásra nem szeretnénk joinolni meg úgy általában semmit).
Kereséshez meg offline/fulltext, ahogy a kolléga mondja.
Az igény úgy szól, hogy a monitor előtt ülő Gizike fog egyszercsak egy új adatot definiálni mondjuk egy üzleti partnerhez? Vagy a rendszert megrendelő ügyfél (cég) igényelhet ilyen új adatokat esetleg egy admin felületen? Szerintem a nagy versenyzők (pl. SAP) is csak külön fejlesztéssel tudnak ilyet, akkor viszont plusz táblákat vezetnek be és az alkalmazás-réteget is módosítják.
Úgy képzelted egyébként, hogy minden táblához lesz egy standard, jól definiált, szép alapverzió, és mellé egy kusztomizálható?
Használtuk a serialized blob-ot, de nem csak erre szorítkoztunk. Voltak “sima” mezők is + materializált mézők az xml-ből (ezek csak a könnyebb kereshetőség miatt).
Ez a baj az EAV-val, meg ennek a serializált blob verziójával is, hogy lassú és csak részlegesen típusos.
Sajnos az ilyen megoldásokkal, az a baj, hogy mindenre jó, de mindenre lassan/rosszul működik. Ilyen megoldások vannak a CRM rendszerek legtöbbjében is, ezért ezek nem is működnek túl jól. Ja és az XML rengeteg helyet foglal el, ha indexeled, akkor meg még többet! :(
SharePointban van egy tábla amely 10 oszlopot tartalmaz típusonként (tehát van vagy 50-60 oszlopa), és a SP Listák egyes mezői ebbe a táblába képződnek le. A leképezés a Lista metaadataiban van leírva. Ha egy típusból esetleg elfogyna a 10 oszlop, akkor nyit egy új DB rekordot a nem elférő SP mezőknek. Így egy SP lista sort a DB-ben 1-(3,4,5, lényeg, hogy kevés) rekord képez le. Tapasztalataim szerint legtöbbször egy SP sor egy DB rekordba belefér.
Szerintem ez ilyen köztes megoldás, és szerintem a SharePointnál elég jól beválik.
Még 1 ötlet: sparse column, és feladatokkal leírni,
Hogy melyik mező, mit tartalmaz, hasonlóan mint
a sharepoint. (és mint sok más portálserver)
Köszönöm mindenkinek a hozzászólásokat. A Szindbad által írt megoldás érdekes, teljesítmény szempontból okos kompromisszum, csak nehéz benne keresni (10x or a whereben).
Egyelőre maradunk a gonosz sima EAV-nál, meglátjuk, hogy zenél.
rgeorge: igen, lesznek alaptáblák, és azokat egészítik ki az ügyfelek saját adatokkal.
feladatok = metaadatok
htc sense kicserélte :(