Kicsit hosszú lesz, elnézést kérek.
Szeretnék egy (növény-, állat-)határozót létrehozni (ezt még nem döntöttem el: általános határozó legyen, vagy külön webhely legyen a növényhatározó, a csigahatározó, a madárhatározó stb. Jó lenne eldönteni, mert tartalomszervezés szempontjából nagyon nem mindegy).
Három főbb használati eset van:
- Keresés
- bárki kereshet, beleértve a névtelen látogatókat is.
- "Keressük azt a madárfajt, aminek a csőre sárga, a szélső faroktollai fehérek, a hosszúsága 32 cm."
- Szerkesztés
- csak az adminok és a szerkesztők szerkeszthetnek
- "Szerkeszteni" = új Fajt, Tulajdonságot, Alkotórészt hozzáadni (egyedtípusok: lásd alább).
- Néhány modattal kifejezve:
- Új taxon hozzáadása (pl.: "Erdei pinty")
- Tulajdonságok hozzáadása: "Az erdei pinty szélső faroktollai fehérek, hossza 14-16 cm, stb."
- aki csak szerkesztő, ne láthassa az /admin/... felületet. A szerkesztő nem érti a Drupal logikáját, csak szakmai szempontokat figyelembe véve rendszerez és tölt fel adatokat
- Adminisztráció, webhely építés
- Sminkelés, az egész logika felépítése (/admin/... oldalak), Drupal ismerete
A következő egyedtípusok körvonalazódnak (hadd használjam most ezt az adatmodellezésből kölcsönvett kifejezést):
- Taxon - a határozás célja, nem feltétlenül faj (pl.: fészkesvirágzatúak családja, vagy hím erdei pinty(ez utóbbi még csak nem is taxon))
- Alkotórész - amikor tulajdonságokat adunk meg, leggyakrabban nem az egész fajhoz rendeljük azt, hanem annak egy részéhez: "az alsó szárlevelek széle csipkés", a "csőr színe sárga".
Részemről megkülönböztetném az Alkotórésztípust és az Alkotórész példányt (előfordulás). Előbbire példa a Virág (általában. Ez rendelkezik lehetséges tulajdonságokkal, pl.: virág színe), utóbbira a tavaszi kankalin virága (ebben rendelünk a lehetséges tulajdonságokhoz lehetséges értékeket, pl.: a virág színe: sárga) - Tulajdonság - az Alkotórésztípussal 1-N kapcsolatban van az N oldalon. Ez a kapcsolat olyan mint egy érvényesítő tábla, amiben megadjuk, hogy egy alkotórésztípushoz mely tulajdonságokat rendelhetjük hozzá
- Érték - a Tulajdonsággal 1-N kapcsolatban van az N oldalon. Ez a kapcsolat is olyan mint egy érvényesítő tábla.
- ...van még pár, de a lényeg ennyi.
A relációs adatmodellben az egyedtípusokból lesznek a táblák (nagyjából). A táblák mezői hasonlítanak a Drupal tartalomtípusainak mezőire, ezért a fenti egyedtípusokból tartalomtípusokat csináltam, de beleütköztem ebbe a problémába. Ott pp a taxonómiát javasolta, de nem találom, hogy a taxonómia hol illeszthető be ebbe az egész kócerájba.
Van még egy csomó dolog, amit itt nem írtam le, de már így is kínosan hosszú lett a téma.
Hogyan kéne ezt az egészet megszervezni?
Miért ragaszkodsz ennyire a
Miért ragaszkodsz ennyire a Drupal megoldásaihoz? Nem kell mindenre ráerőltetni ha nincs kézzelfogható előnye.
erőltetni?
Mit értesz erőltetés alatt? Te mit tennél?
- Nem Drupalt használnál
- Drupalt használnál, de saját modullal oldanád meg
PS: inkább így kérdezem: melyik részét bíznád a Drupal eszközeire és melyiket saját modulra?
Fox Mulder
Computed Field, Content Taxonomy
Mostanában dolgoztam egy hasonló összetett honlapon, van kb. 50 tartalomtípus, 70 CCK mező és nem-tudom-hány taxonómia kategória. Pár helyen Computed Field modul segítségével a taxonómia kategóriák értékeit lementem CCK mezőkbe is. Erre vannak kész megoldások (pl. a Content Taxonomy), de én feleslegesnek találtam pár sor PHP kód kiváltására feltenni még egy modult. A Computed Field egyszerű, fapados, de nagyon jól használható ilyen esetekben.
A CCK mező általában nagyobb mozgásteret ad, mint a Taxonómia – másrészt viszont egy sor modul és szolgáltatás csak Taxonómiával működik. Ilyenkor ha nem kell nagy terhelésre tervezni, akkor célszerűbb lehet duplán tárolni adatokat term-ként és field-ként is, mint nulláról fejleszteni egy alkalmazást. Nem nyersz vele adatbázis-szépségversenyt, viszont egy nagyságrenddel csökkenthető a fejlesztés időigénye és költsége, ami azért már elég vonzó lehetőség.
Köszönöm
Köszönöm a választ. Mit jelent a "nagyobb terhelés"? A látogatottság mértékét (500 felhasználó egyszerre), vagy a node-ok számát?
Fox Mulder
sok tábla
Ha megnézed az adatbázist, a CCK sok kis táblába szórja szét az adatokat (főleg ha egyes mezőket újrahasznosítasz, azaz több tartalomtípusnál is felhasználsz, minden ilyen mezőnek külön táblája van).
Amikor megjelenítesz egy node-ot sok CCK-s mezővel, akkor ezeket a táblákat össze kell kapcsolni (join). Ha még ráadásul duplán le van mentve az adatok egy része (taxonómia kategória és CCK field), az megint csak nem javítja a teljesítményt. Ha egy listázó oldalon sok node-ot listázol, vagy egyszerre sok lekérdezés jön (látogatottság), vagy a táblák nagyon nagy méretűek (több százezer node a rendszerben), megint csak keményen dolgoztatod az adatbázist.
Lényegében a fejlesztés költségének csökkentését az adatbázissal fizettetjük meg – pedig többnyire az adatbázis a legszűkebb keresztmetszet egy szerveren. Ezért nem lehet nagyobb méretű és/vagy forgalmú webhelyet anélkül összekattintgatni, hogy értenénk ami a háttérben megy. Ajánlott könyv és kapcsolódó blog.
Egyik lehetséges megoldás amit éppen a napokban alkalmaztam, hogy az adatokat összevonjuk egy denormalizált táblába, amit cronnal tartunk karban. (Ez persze egy sor új problémát vet fel.)
Köszönet ezért is
Most van egy működőképesnek tűnő verzió, ami (pp javaslatára) inkább a taxonómiára épül (és a Content Taxonomy modulra), de ezzel is vannak problémák (ezt most nem érdemes részletezni). Az egész csak hobbi, nincs határidő ezért inkább saját modult ütök össze. Node-ok közötti kapcsolatokról van szó (az egyik node, pl.: egy alkotórész egy másik node (egy faj) alárendeltje, vagy egy tulajdonság csak egy bizonyos alkotórésztípussal kapcsolatban értelmezett, stb.), tehát néhány saját kapcsolótáblát kell csak lekezelni. Még nem tudom, hogyan, de körvonalazódik...
Fox Mulder
off
ez a mondat nagyon tetszik. Sose tudtam eleg tomoren megfogalmazni mi az ami a CCK modulban zavar. Tudom, hogy te nem a CCK modulra mondtad..