Pozdrav svima.
Malopre sam počeo da radim svoje univerzalno cms rešenje, što zbog cv-a, što zbog kasnijeg korišćenja ako klijenti ne žele open source CMS rešenje.
Do sada sam uglavnom postavljao svoje jednostavne cms-ove ili sam povezivao sa jumlom.
Sada sam uradio samo deo EER dijagrama, ostaje deo sa pozicijama i menijima, ipak bih voleo da admin ima mogućnost dodavanja i nove meni kartice, to znači da ću morati da radim nešto slično kao jumla. Da ubacim i pozicije za printanje osnovnog članak modula...
Ovu temu ću koristiti kada baš zapnem za nešto gde se ne mogu iščupati, mada što se tiče baza podataka uvek se mogu iščupati, to je moje područje hehe, ali saveti su dobrodošli...
Da pređem na stvar, prvo pogledajte ovaj "basic" eer dijagram.
Administrator objavljuje više članaka, Članak može objaviti veći broj administratora, otud i agregacija između dva entiteta u vidu entiteta AdminČlanak u kom pamtim vreme kada je Admin/Moderator objavio Članak. Kada smo već kod Admina i Moderatora, šta mislite da li da napravim i entitet za Moderatora kao slab entitet (O-M) Administratora. Ili pak da to definišem u samom CMS-u i da takva podešavanja pamtim u jednom XML fajlu?
Tipa moderator može da objavi članak, ali ne može obrisati administratora, samom definicijom baze child ne može obrisati parent, u ovom slučaju Admin bi spustio ključ u Mod-a i Mod nebi mogao da ga obriše.
Više članaka može biti u jednoj kategoriji ili podkategoriji, otud i kategorija spusta ključ u članak, i ovde sam razmišljao o agregaciji jer jedan isti članak ili medij može biti u većem broju kategorija ili podkategorija? Podkategorija je slab entitet Kategorije jer od nje zavisi.
Korisnik objavljuje nula ili više Komentar-a...
I to je u suštini sva logika ovog cms-a, e sada trebaju mi predlozi šta još?
Ubaciću i entitet/tabelu meni i podmeni koji će biti agregacijom povezani sa člankom.
Šta bih još mogao da ubacim što će mi biti kasnije potrebno?
Kontao sam da sva konfiguracija cms-a ide preko XML fajla, slično kao i pozicije u jumli, s tim da ja neću koristiti pozicije nego ću samo "ispisati" ono iz baze na određenoj poziciji.
Imam još dva pitanja,
da li da radim ovo preko CodeIgnitiera, služeči se MVC tehnologijom ili klasičnim OOP načinom? i
da li da napravim sve potrebne procedure za Insert, Update, Delete kao i poglede i funkcije za Select u bazi ili da to radim u programu preko klasičnog $mysqli->query(string) načina? Negde sam čuo da se upiti brže izvršavaju sa procedurama, nego sa upitima.
A i lakše je sve što ima veze sa bazom definisati u bazi, pa samo pozvati u modelu preneti controlerom na pogled i obratno, nego u modelu praviti glomazni kod oko upita...
Hvala.
Evo već znam da mi fale kolone za broj pregleda, lajkove, ban itd, ali to manje više, bitna mi je povezanost i koji su mi entiteti neophodni...
Malopre sam počeo da radim svoje univerzalno cms rešenje, što zbog cv-a, što zbog kasnijeg korišćenja ako klijenti ne žele open source CMS rešenje.
Do sada sam uglavnom postavljao svoje jednostavne cms-ove ili sam povezivao sa jumlom.
Sada sam uradio samo deo EER dijagrama, ostaje deo sa pozicijama i menijima, ipak bih voleo da admin ima mogućnost dodavanja i nove meni kartice, to znači da ću morati da radim nešto slično kao jumla. Da ubacim i pozicije za printanje osnovnog članak modula...
Ovu temu ću koristiti kada baš zapnem za nešto gde se ne mogu iščupati, mada što se tiče baza podataka uvek se mogu iščupati, to je moje područje hehe, ali saveti su dobrodošli...
Da pređem na stvar, prvo pogledajte ovaj "basic" eer dijagram.
Administrator objavljuje više članaka, Članak može objaviti veći broj administratora, otud i agregacija između dva entiteta u vidu entiteta AdminČlanak u kom pamtim vreme kada je Admin/Moderator objavio Članak. Kada smo već kod Admina i Moderatora, šta mislite da li da napravim i entitet za Moderatora kao slab entitet (O-M) Administratora. Ili pak da to definišem u samom CMS-u i da takva podešavanja pamtim u jednom XML fajlu?
Tipa moderator može da objavi članak, ali ne može obrisati administratora, samom definicijom baze child ne može obrisati parent, u ovom slučaju Admin bi spustio ključ u Mod-a i Mod nebi mogao da ga obriše.
Više članaka može biti u jednoj kategoriji ili podkategoriji, otud i kategorija spusta ključ u članak, i ovde sam razmišljao o agregaciji jer jedan isti članak ili medij može biti u većem broju kategorija ili podkategorija? Podkategorija je slab entitet Kategorije jer od nje zavisi.
Korisnik objavljuje nula ili više Komentar-a...
I to je u suštini sva logika ovog cms-a, e sada trebaju mi predlozi šta još?
Ubaciću i entitet/tabelu meni i podmeni koji će biti agregacijom povezani sa člankom.
Šta bih još mogao da ubacim što će mi biti kasnije potrebno?
Kontao sam da sva konfiguracija cms-a ide preko XML fajla, slično kao i pozicije u jumli, s tim da ja neću koristiti pozicije nego ću samo "ispisati" ono iz baze na određenoj poziciji.
Imam još dva pitanja,
da li da radim ovo preko CodeIgnitiera, služeči se MVC tehnologijom ili klasičnim OOP načinom? i
da li da napravim sve potrebne procedure za Insert, Update, Delete kao i poglede i funkcije za Select u bazi ili da to radim u programu preko klasičnog $mysqli->query(string) načina? Negde sam čuo da se upiti brže izvršavaju sa procedurama, nego sa upitima.
A i lakše je sve što ima veze sa bazom definisati u bazi, pa samo pozvati u modelu preneti controlerom na pogled i obratno, nego u modelu praviti glomazni kod oko upita...
Hvala.
Evo već znam da mi fale kolone za broj pregleda, lajkove, ban itd, ali to manje više, bitna mi je povezanost i koji su mi entiteti neophodni...
:: ::::