ugrás a tartalomhoz

Tárolás: adatbázis vagy tömb?

iddqd · 2012. Jún. 5. (K), 13.03
Sziasztok!
Lenne egy elméleti kérdésem.
Egy oldal esetlegesen változó, szerkeszthető elemeit ( menüpontok, választható lista elemek stb ) szeretném valahogyan tárolni. Ezeket az admin felületről lehet, bővíteni, szerkesztetni, hozzáadni és így tovább. Arra gondoltam, hogy ehhez nem kellene külön plusz táblát, akár többet is létrehozni az adatbázisban, hanem csinálok egy config fájlt és abban tömbökben tárolnám és ezeket szerkesztgetem később, illetve olvasom be. Szóval ha vannak előnyei vagy hátrányai a különböző
megoldásoknak, akkor mik lennének ezek? Hogyan lenne érdemes ezt megoldani?
Köszönöm!
Üdv
‹ input form name megadása SQL adatbázisból és $POST kérdés Nagy fájlok kiszolgálása PHP-vel ›
 ■
1

Keresés

Poetro · 2012. Jún. 5. (K), 13.11
A keresés és szűrés egy idő után kevésbé lesz hatékony egy saját megoldás esetén. Azaz ha van már több ezer, vagy millió bejegyzés, akkor nem igazán hatékony ezeket config fájllal kezelni. Valamint ennek a config fájlnak az írását és olvasását is neked kell megoldani, ami nem feltétlen triviális probléma.
2

Kizárólag oldal elemekről van

iddqd · 2012. Jún. 5. (K), 13.30
Kizárólag oldal elemekről van szó mint pl a navigációs menük. Bejegyzések, hírek, és az ilyen értelembe vett tartalom mind adatbázisba megy. Beszélünk itt tömbönként kb 5-10 elemről max ( "értékről" ).
3

Egy példa: Van egy oldalmenü,

iddqd · 2012. Jún. 5. (K), 13.43
Egy példa:
Van egy oldalmenü, városok felsorolva, ami lényegében az adott város alapján szűri a találatokat. Ezeket szeretném estlegesen később szerkeszteni, hozzáadni vagy elvenni akár. Őket tárolnám adatbázis helyett a config fájlban, tömbökben. De akkor ha jól értelek, a kezelésen kívül sok különbség nincs a két megoldás közt?
Kösz Poetro
4

Ha pl. nagyon ritkán változó

_lacus_ · 2012. Jún. 5. (K), 14.05
Ha pl. nagyon ritkán változó menüpontokról (kapcsolat|magunkról|ászf stb) van szó, akkor azt szerintem nyugodtan veheted config fájlból, vagy akár közvetlenül is beírhatod a html-be, vagy a php template-be.

Ami a városos példát illeti, az helységeket szerintem érdemesebb adatbázisban tárolni és cache-be rakni. Így kezelhetőbb lesz és az esetek legnagyobb részében megspórolsz egy adatbázist hívást is. Természetesen módosításnál, törlésnél, vagy új helységek hozzáadásánál, továbbá minden, a helységeket is érintő változásnál frissíteni kell a helység cache-t.
5

Azért nem akarom közvetlenül

iddqd · 2012. Jún. 6. (Sze), 11.00
Azért nem akarom közvetlenül a template -be írni, mert úgy macerásabb lenne a változtatás. Pláne ha nem én csinálom. Van egy felület a cms -ben, ahol lehet újat felvinni, innét lenne a szerkesztés. Eredetileg azért is választanám ezt a megoldást mert lenne pár ehhez hasonló "lista", ( városok, kategóriák stb )és nem szerettem volna mindegyikhez külön táblát létrehozni. ( és így is megspórolnám az adatbázis hívást )
6

Viszont úgy látom, mindenki

iddqd · 2012. Jún. 6. (Sze), 13.35
Viszont úgy látom, mindenki inkább a db -re szavaz... Kitalálom akkor hogy lehetne a legkevesebb táblából összehozni őket.
7

JSON

Hidvégi Gábor · 2012. Jún. 7. (Cs), 13.00
Ha tényleg kevés az adat, akkor lehet érdemes lenne JSON formában fájlba menteni, mert ezt elég könnyű kezelni, és valamivel gyorsabb is lehet, mint adatbázisműveletekkel elvégezni a munkát.
8

Ennek utána nézek mindenképp!

iddqd · 2012. Jún. 8. (P), 12.57
Ennek utána nézek mindenképp! Köszönöm a tippet!
9

Egyetlen tábla, két mező

Pepita · 2012. Jún. 10. (V), 19.58
Első mező : `list_id` INT(10) KEY
Második: `serialized_data` TEXT INDEX

Asszem így magáért beszél, ha nem érthető, szólj.
10

Arra gondolsz, hogy az összes

iddqd · 2012. Jún. 12. (K), 12.05
Arra gondolsz, hogy az összes összetartozó "elemnek" ( menük, listák stb ) adjak egy csoport id -t és szórjam be egy táblába, aztán ez alapján kérdezzem le őket később? ( + cache ) Nekem is hasonló jutott eszembe már, csak arra voltam kíváncsi használtok e más/jobb módszert lespórolva a plusz táblát meg a lekérdezéseket.
Köszönöm a tippet, talán ez lesz a legszimpatikusabb.
11

Egy csoport = egy rekord

Pepita · 2012. Júl. 3. (K), 01.30
Ezt nézd meg.
Akár egymásba ágyazott (PHP) osztályok példányait is el tudod vele menteni (és vissza), ha komplett HTML-t akarsz (az nem biztos, hogy jó irány!), akkor escape-elni kell és kész. Te döntöd el, hogy mit akarsz egy csomagba tenni. Ha keresni akarsz benne, akkor az legyen a legfontosabb, hogy "könnyű dolga" legyen a mysql (vagy egyéb) szervernek. (Esetleg emiatt egy-két plusz oszlop kellhet.)
Nekem adatbázis-tervezésben egy fontos kiindulópont, hogy ha van vmi ilyesmi a Drupal-ban, az hogyan és miért úgy tárolja. Sok okosságot lehet tanulni fejlesztőitől.