Rád by som k článkom, blogom, vo fóre ... proste k jednotlivým objektom databázy priradil systém komentárov. Komentáre teda aby boli jednoznačne priraditeľné k iným databázovým objektom musia obsahovať cudzí kľúč a typ objektu. Ak hovoríme o článkoch ako o objektoch tak tie sú prirodzene číslované (1, 2, 3 ...), ale rovnaké číslovanie budú mať aj blogy, takže aby bol komentár priraditeľný musí obsahovať nie len cudzí kľúč (FK), ale aj typ objektu.
Napadli ma k tomuto problému 3 riešenia.
- Vytvorenie tabľky komentárov s id objektu a typom objektu v primárnom kľúči
- ORM, ktoré používam nemá podporu joinov, ktoré nie sú pomocou FK, takže nemôžem urobiť niečo ako JOIN diskusia.obj_id = clanok.id AND diskusia.obj_typ = "clanok"
- Nie je to práve najčistejšie riešenie (nebudú tam definované FK)
- )Lahko realizovateľné fulltext vyhľadávanie
- Vytvorenie samostatnej tabuľky diskusie pre každý typ objektu
- ľahko realizovateľné pomocou ORM, ktoré používam (pomocou abstraktného modelu a dedičnosti)
- Jednoduché čisté FK
- Pri zmene štruktúry je nutné zmeniť niekoľko tabuliek
- Fulltext s unionmi (pomalé ako teraz, ale nie je až tak podstatné, viz. odstavec o fulltext vyhľdávaní)
- Zavedenie jednoznačného ID entitám, čo je ralizovateľné rôznymi spôsobmi:
- Vytvorením sekvencie a pridaním ďalšieho jednoznačného ID ku každej entite, ktorá má mať komentár
- Škaredé riešenie, ale realizovateľné pomocou FK
- Nie je relizovateľné vo všetkých DBS
- Vytvorenie tabuľky, v ktorej budú naraz články, eshop, blogy ... proste taká tabuľka pre všetko, niečo ako wp_content
- Veľmi ľahko relizovateľný fulltext
- Realizovateľné pomocou FK, modely s vlastným managerom
- Jednoduchý fulltext
- Hrozná správa, managovateľnosť, neprehľadné
- Vytvorenie tabuľky obsahujúcej len ID diskusie a pridanie FK na túto tabuľku jednotlivým entitám
- Prístup cez FK
- Nutnosť zavedenia tabuľky navyše
- Nie práve najpríjemnejšia správa
- Vytvorením sekvencie a pridaním ďalšieho jednoznačného ID ku každej entite, ktorá má mať komentár
Ako databázu by som rád použil postgresql, ktorá má aj pri veľkej záťaži fakt skvelý výkon. Ak by mysql vymenil za postresql nebolo by možné urobiť fulltext vyhľadávanie v databáze. Na druhej strane rád by som na vyhľadávanie namiesto databázy použil rovnako ako na abclinuxu Lucene. V takom prípade sú moje výhrady k vyhľadávaniu totálne irelevantné.
Ak máte nejaké argumenty pre / proti, prípadne poznáte nejaké iné možnosti sem s nimi ;)
PPS. Ak hovorím o zvýšení výkonu nového CMS nepôjde len o nejaké kozmetické zmeny, ale dúfam aj prepis do iného jazyka, iná databáza, konečne poriadny vyhľadávací engine ... Experimentujem momentálne s djangom, podľa benchmarkov vyzerá, že by to mohlo s JIT slušne rozdupať systémy založené na PHP, rovnako Postgresql vs MySQL. Inak ešte trochu z histórie Shakal CMS, tento názov sa mi celkom páči a nový systém by som chcel nazvať Shakal-NG (hoc názov takmer rovnaký ide o kompletný prepis všetkého). Tento systém som robil dávno a dovtedy som mal prax s PHP asi mesiac, celkovo keď som tu začínal mal som počítač asi pol roka. Ak hovorím, že dokážem niečo napísať lepšie zvyčajne nekecám hoc by som kvôli tomu mal spávať dve hodiny denne.
Toľko informácie na dnes, idem ja zatiaľ pracovať, prajem príjemný zvyšok dňa.
PS: Sa začali vracať staré páky, čo sa deje :)
select max(seq_id)+1 from blaha neodpamätáš si to do tabuľky emulujúcej samotný objekt sekvencer.Inak, ja skôr vidím iný problém. Zamykanie záznamov v referenčných tabuľkách a rekonštrukcia konzistentnosti záznamov pri (ehm nazvime to) reštarte. Ale, to závisí od konkrétneho databázového engine.
Čo dodať, paráda :)