Citat:
NetworkAdmin:
Da bas sam citao negdje na mailing listi smartijevoj da covjek koji prakticno razvija smarty je napisao da je pomisljao da napravi nesto sto govorimo ovdje "totalno uopstenje" ali je zakljucio isto sto i ti... negdje se mora povuci crta. Specijalizovani kodovi mozda ne izgledaju tako lijepi kao neki opsti ali zato su brzi...
Naravno, prva star je brzina, ali takodje i lakoca korsicenja je bitna. Uopsteni metod zahteva mnogo parametara a podaci umeju da budu zaguljeno zatpani iza nekih komplikovanih mehanizama.
Kad smo kod toga evo jednog slucaja nakome trenutno radim.
Stvar je u uobicajenoj bazi sa podacima o korisnicima i njihovom koriscenju iz vise modula. Za razne primene, potrebni su razlicti podaci o korisnicima i treba smisliti mehanizam koji omogucava a svaki modul koji iz nekog razloga treba da korsiti podatke o korisnicima ili cak uvodi neke svoje to moze da uradi jednostavno.
Reseje kome se cest pribegava, da se naprvi tabela parametara koja omogucava da se podaicma pristupa preko kljuceva je prilicno opste i zaista moze da pokrije gomilu raznih podataka cak i bez promene u strukturi baze podataka. Pojednotavljeno, svodi e na uvodjenen tabele parametara koja ima strukturu ID_MODULA, ID_PARAMETRA, VREDNOST pa se sa malim skupom funkcija parameri mogu definisati, upisivati i citati. Komplikacija je sto parameri mogu biti raznih tipova pa to treba da bude podrzano. Ono sto je poseban prolemje sto se ovako definisanim parametrima, ne moze pristupiti jednim jenostavnim SELECT-om nego mora da se petlja.
Resenje o kome razmisljam je drugacije. SVaki modul ima sopstvenu tabelu korsinika u koju upisuje podatke onako kako njemu odgovara. Tabele korisnika svih modula su medjusobno povezane po kljucnom polju (ID-KORISNIKA) u relaciji 1 - 1. Podaci se citaju JOIN-ovanjem tabela korisnika iz potrebnih modula.
NA primer, apliakciaj moze da ima tabele:
AUTH_KORISNICI, sa kljucnim polje ID_KORISNIKA i dodatnim poljima potrebnim za utentifikaciju (korsinicko ime, lozinka, vreme kreiraja, vreme poslednje posete, ip sa kojeg je bila poslednja poseta i slicno)
PROFIL_KORISNICI, sa kljucnim poljem ID_KORISNIKA i dodatnim poljima vezanim za profil (ime i prezime, datum rodjenja, adresa, telefon i svi ostali podaci koji su potrebni).
Podaci o korisniku se dobijaju po potrebi JOIN-ovanjem slogova ove dve tabele. Tabele se nezavisne i svaki modul moze da im definise strukturu po sopstvenoj potrebi ne uticuci na ostale module.
Sad recimo da u apliakciju treba uvesti modul za forum. I njemu su potrebni specificni podaci o korisnicima. taj modul kreira svoju tabelu FORUM_KORSINICI koja opet ima kljucno polje ID_KORISNIKA i dalje samo ona polja koja su potrebna forumu. Po potrebi i ova table se preko relacije lako JOIN-uje sa prethodne dve i podaci se mogu dobiti na jednom mestu.
Onda se ispostavi da se alikacija radi za biblioteku, pa je potrebno da se vodi evidencija o clanovima, sa specificnim podacima. Dodaje se tabela BIBLIOTEKA_KORISNICI opet sa kljucnim poljem ID_KORSINIKA i dalej specificnim podacima za biblioteku.
Ono sto je potrebno to je da modul apliakciji na neki nacin saopsti da ima sopstvenu tabelu korsinika, kako i ova znala da je upotrebi.
Ovaj nacin nije toliko felskibilan i uopsten kao prvi, i zahteva promenu u strukturi baze, medjutim daje vecu brzinu prstupa podacima i po meni, mnogo jednostavniji pristup podacima.
Pretpostavljam da se jos neko bavio ovim problemom i da ovo sto sam smislio nije nista novo, posto je logicno resenje. Interesuju me iskustva drugih i eventualni problemi koji su mi promakli.