node szerü tartalom mentése db-be
Sziasztok!
Ezt inkább vitatémának szánom, mert tudok rá megoldást, kettő megoldást (ha valaki tud egy harmadikat, ne tartsa magában) és megtudom találni melyik a legjobb :)
A cél: csm tartalom mentése adatbázisban, a cms oldalon lévő "slotokat" a felhasználó adhatja meg admin felületen, úgy mint szöveges mező, cím mező, kép mező, szám mező stb. A megadott template-el ezek lesznek megjelenítve.
A form/template/tipus megvalósítását most hagyjuk, adatbázisban az egyes oldalak elmentésére koncentrálok.
két lehetséges megoldáson gondolkozok, a 2-at részesítem előnyben:
1. megoldás, fő tábla node, erre vannak adattípusonként csatolva táblák, úgy mint node_string, node_integer, node_real, node_text, node_date, node_datetime stb.
előny: db-ben kevesebb helyet foglal a 2. megoldáshoz képest
hátrány: keresés megvalósítása bonyolultabb, egyes slot tipusoknál tárolnom kell, hogy milyen adattipus tartozik hozzá (bonyolítja a megvalósítást, 2. megoldásnál elég csak validálni az adatot)
2. megoldás, fő tábla node, erre van egy tábla node_content csatolva, amiben egy longtext mező tárolja az adatot és fulltext index van rátéve a kereséshez.
előny: nagyon egyszerű és gyors a keresés
hátrány: kisebb adatok (pl: szám, dátum) is egy longtext mezőbe írjuk bele, adatbázisban tárolás szempontjából ez így csúnya
----
mindkét esetben kérdéses a sebesség, leginkább a keresés sebessége, tesztelni fogom mondjuk 1 millió adattal (200.000 node, mindegyikhez 5 adattipus), fulltext search miatt a 2. talán gyorsabb lesz, nem tudom ekkora adat mennyiségnél hogy viselkedik...
■ Ezt inkább vitatémának szánom, mert tudok rá megoldást, kettő megoldást (ha valaki tud egy harmadikat, ne tartsa magában) és megtudom találni melyik a legjobb :)
A cél: csm tartalom mentése adatbázisban, a cms oldalon lévő "slotokat" a felhasználó adhatja meg admin felületen, úgy mint szöveges mező, cím mező, kép mező, szám mező stb. A megadott template-el ezek lesznek megjelenítve.
A form/template/tipus megvalósítását most hagyjuk, adatbázisban az egyes oldalak elmentésére koncentrálok.
két lehetséges megoldáson gondolkozok, a 2-at részesítem előnyben:
1. megoldás, fő tábla node, erre vannak adattípusonként csatolva táblák, úgy mint node_string, node_integer, node_real, node_text, node_date, node_datetime stb.
előny: db-ben kevesebb helyet foglal a 2. megoldáshoz képest
hátrány: keresés megvalósítása bonyolultabb, egyes slot tipusoknál tárolnom kell, hogy milyen adattipus tartozik hozzá (bonyolítja a megvalósítást, 2. megoldásnál elég csak validálni az adatot)
2. megoldás, fő tábla node, erre van egy tábla node_content csatolva, amiben egy longtext mező tárolja az adatot és fulltext index van rátéve a kereséshez.
előny: nagyon egyszerű és gyors a keresés
hátrány: kisebb adatok (pl: szám, dátum) is egy longtext mezőbe írjuk bele, adatbázisban tárolás szempontjából ez így csúnya
----
mindkét esetben kérdéses a sebesség, leginkább a keresés sebessége, tesztelni fogom mondjuk 1 millió adattal (200.000 node, mindegyikhez 5 adattipus), fulltext search miatt a 2. talán gyorsabb lesz, nem tudom ekkora adat mennyiségnél hogy viselkedik...
Több megoldás
entity_id,field_id,value. Ugye ebben az esetben majd kell még egy lekérdezés, ami lekérdezi az entity típushoz, hogy melyik mezőnek mi a neve, és mi a mezőknek a sorrendje. A 200 ezer tartalom nem tűnik túl soknak, ennél sokkal több adattal is kényelmesen el kell boldogulnia az adatbázisnak.A 2-es megoldást semmiképp se alkalmaznám, semmi előnye nincs, csak hátránya.
Bevezetnék egy harmadik megoldást, ami Document Store alapú, így az adat tárolásának gondja le van tudva, mivel eleve a táblákban dokumentumot tárolunk. Erre lehet például CouchDB-t vagy MongoDB esetleg Redis (bár ezt bonyolultabb megoldani).
A kereséshez minden esetben például Apache Solr-t illetve Sphinx-et használnék.
mysql vonalon kell
Nincsenek mezők csak egy
szükséges mezők ott is
Lekérdezésben így egyből rálehet csatolni a node-ra az összes tipust egy join-al. Nagyon szépen hangolható a keresés fulltext miatt, type_id megadásával lehet csak egyes tartalom tipusokban keresni. Létrehozásnál kell arra figyelni hogy adott node-ra az összes elvárt slot tipushoz legyen egy adatbázis bejegyzés, akkor is ha üres a tartalma.
SQLFS
Ma mar lehet mas megoldast valasztanek, de meg nem mondom, mit.