Struktura databaze pro nastaveni web aplikace a dedicnost doctrine
- Ja
- Člen | 260
Zdravim,
programuju eshop v nette + doctrine a rad bych, aby si uzivatel mohl hodne veci customizovat sam.
Jak byste postavili architekturu pro desitky moznych nastaveni? Mam tu navrhy:
- Tabulka se sloupci | klic | hodnota | ⇒ moc se mi tohle reseni nelibi, protoze app bude castecne odstinena od toho, co vlastne v te tabulce je ulozeno
- velka tabulka, kde jeden sloupec je jedno nastaveni a bude tam jeden zaznam… ⇒ zde uz se to blizi necemu co by se mi libilo, properties budu mit pekne v entite, budu s tim pracovat v app jako s objektem
- posledni uvaha ktera me napadla byla vzit b), tzn velkou tabulku a nejak ji dekomponovat na tabulky typu settings_seller, settings_date_time atd… – toto reseni by se mi hodne libilo a predstavoval bych si to jako nejakou entitu Settings, ktera bude mit potomky SettingsSeller, SettingsDateTime, ktery uz budou mapovat vlastni properties. A k tomu vsemu bych pristupoval pres jeden objekt ‚Settings‘.
Je zpusob c) vubec v doctrine mozny? Jak byste tento problem resili, aby to bylo hned od zacatku postaveno spravne, transparentne, a aby se to krasne dalo pouzivat napric celou aplikaci?
Moc diky za navrhy!
Ja
- Lukeluha
- Člen | 130
Doctrine umí dobře pracovat s dědičností, zrovna tady by se nejspíš dalo použít single-table inheritance (popř. pokud jednotlivá nastavení nebudou mít pouze jednu hodnotu, ale více, tak poté spíše class table inheritance) a jednotlivé nastavení bych házel rovnou do session při přihlášení, ať nemusíš pokaždé šahat do db.
Popř. pokud těch nastavení nebudou desítky, tak by klidně stačilo mít jednu tabulku (což je vlastně tvá varianta b). Dědičností vždy zvýšíš režii a pokud není úplně potřeba, není důvod ji tam cpát uměle.
Editoval Lukeluha (26. 8. 2015 7:19)
- Ja
- Člen | 260
@Lukeluha : Jj, moc diky, kazdopadne, ja jsem pak jeste neco o te dedicnosti googlil a nakonec jsem skoncil u toho, ze budu mit pro kazde nastaveni separatni entitu, pri inicializaci se vzdycky udela defaultni jeden zaznam, se kterym se bude pracovat. Zatim mi to dava smysl – mit vic tabulek – SettingsVat, SettingsSeller atd.
Kdyz budu potrebovat pridat nastaveni, pridam ho do konkretni entity, zpropaguju dp databaze a pouzivam. Ale urcite to nechavam otevreny, mozna na nejaky uskali narazim az casem.
- akadlec
- Člen | 1326
btw je nutné mít settings jako entitu? Já to řeším tak že settings pokud jej ukládám do db, tak jej uložím v poli převedeném na json string. V appce si ji pak načtu do služby $settings a přistupuji k ní přes getter či setter:
$settings->get('pocet_produktu_na_stranku', 10);
$settings->set('pocet_produktu_na_stranku', 10);
$settings->get('produkt.zobrazit_diskuzi', FALSE);
při editaci se pak dají data vytáhnout třeba jako pole nebo json string a uložit do db, či jako pole do neonu.
Tabulka s nekonečným počtem sloupců mě nepřipadá jako úplně košér.
