Meddig erőltethető az adatbázis használata, mikortól káros?

 ( atomjani | 2014. március 6., csütörtök - 17:24 )

1. szint, fájlból olvasunk ki adatokat, ha nincs olyan sok.
2. szint, amikor a sok adatot adatbázisban tárolunk, sql nyelven kérdezzünk le és manipuláljuk az adatokat.
3. szint, maga a css, php kódok vagy a php fájlok elérése is adatbázisban van tárolva, ez a része már érdekesebb.

A mai dinamikus weboldalak általában úgy működnek, hogy van írva index.php, kereses.php, adatlap.php, talán blog.php, kinezett.css, jss-cucc.js és a .htaccess-sel a linkek formázva, linkekkel kapcsolatos dolgok is az adatbázisban vannak minden más adatokkal. Tehát nincs weblap.hu/profilok/pista.php.
Már html kódok is vannak az adatbázisban eltárolva, például ha egy blogbejegyzés html nyelven formázta az írója.
A következő lépés az, hogy php nyelven is ír a bejegyzésben vagy egy php fájlt is behúz, a jól megírt weboldal majd használja az include függvényt hozzá, ahogy kell.

El lehet menni a végletekig. Van egy index.php fájl, php nyitó és lezáró tag között mysql-hez csatlakozás és abból lekérdezi az index.php tartalmát. Fizikailag se kereses.php, se css, se js fájl, mindent az adatbázisból olvas ki. Gondolom nem akadály ezt megvalósítani, ha nem tévedek. Csak egy .htaccess és egy index.php láttán egy profi meg csak vakarhatja a fejét, hogy egy nagy tudású weboldalnak hol lehetnek a többi fájljai.
Az igazi kérdés, hogy meddig érdemes elmenni, hogy optimális teljesítményre, jó átláthatóságra, jó használhatóságra tegyünk szert. Gondolom én, hogy számít az is, hogy mennyire dinamikus weboldalt akarunk készíteni.
Nektek milyen tapasztalataitok van ezzel kapcsolatban? Adatbázisban tároltok például php kódokat, amit majd szükség esetén futtatni fog a weboldal?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Remélem ezt most nem gondoltad komolyan (a bejegyzésed egyik pontját sem).
Mindent arra használunk, amire való.


// Happy debugging, suckers
#define true (rand() > 10)

Nyelvtől is függ, hogy mi a jó, mi használható - én vettem részt olyan webes szolgáltatás (kb. 3500 usernek belső portál) fejlesztésében, ahol természetes volt, hogy mindent tárolt eljárásban írunk meg, ergo minden a DB-ben foglal helyet (Oracle IAS). Nekem speciel jobban tetszett, mint péhápében bohóckodni :-P

velemeny: lol

--
NetBSD - Simplicity is prerequisite for reliability

Elképzeltem, amikor szerkeszteni akarod a PHP-kódot:
echo "SELECT php_code FROM code WHERE code_name='index.php'" | mysql > index.php
KedvencSzerkeszto index.php
echo "UPDATE code SET php_code="`cat index.php`" WHERE code_name='index.php'" | mysql

Nagyon egyszerű és könnyen kezelhető, tényleg be kellene vezetni :)
De azért egy-két dolgon elgondolkodtam:
- verziókezeléssel mi lesz?
- ha a látogató böngészőben az index.php-ra hivatkozik, akkor lefut egy lekérdezés az SQL-szerveren (amit mi fog elindítani?), ami "letölti" az index.php-t ÉS azok függőségeit is, és lefuttatja az index.php-t. Nem lesz ez egy "kicsit" költséges és bonyolult? Nem fogsz ezzel gyakorlatilag oda kilyukadni, hogy van egy index.php-d és azok "függőségei" is? Pont oda, ahonnan kiindultál, csak most az egyszerű fájlból kiolvasom, lefuttatom helyett van egy adatbázisból kiolvasom, (valamilyen, fizikai vagy "virtuális") fájlba kiírom, és lefuttatom.

Amúgy sub :)

verziókezelés miatt lenne az adatbázis - minden változást új rekordba, mit nem lehet ezen megérteni?

sub ;)

bar a konkret pelda (.php-k tarolasa), mint ahogy lentebb irtak, vet fel kerdeseket (cache-eles,...), azert az otletet igy leszarozni kicsit nagyarcunak tunik.
SAP-ban sikerult megoldani (evtizedekkel ezelott), hogy a DB-ben legyenek a forraskodok (sot a leforditott bajtkodok is), verziokezeles, package management, teljes lifecycle megoldas van, integraltan all-in-DB modon. Mindezt ugy, hogy sok adatbaziskezelot tamogat. Szoval hatrabb az agarakkal.

+1

hehh, pont ezt írtam.. ;)

Attol, mert valaki leimplementalta, meg nem lesz ertelmes megoldas. Es most rettenetesen uriasan fogalmaztam.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hat, attol fuggetlenul hogy valaki mar megcsinalta, egy baromsag marad.


// Happy debugging, suckers
#define true (rand() > 10)

Na igen, de az SAP-t nem is azért szeretjük, mert mindenhol követi a common sense-t. ;)

Azt hiszem nem ilyesmire gondolsz, de Pl. a CIV5 alatt SQLite van. ;)

1gyébként ha sikerül valami brutál vasat a DB alátenni miért ne lehetne,
azért elég speciális esetnek kell lennie szerintem. ;)

DBben tárolni forráskódot pont olyan, mint root módban futtatni az apache2/php5-t. Lehet, de nem biztos, hogy jól jársz vele.

-------------
"Mérnökkel vitatkozni olyan, mint disznóval birkózni a sárban - kis idő múlva rájössz: Ő ezt élvezi..."
Winben blogja

Hölgyeim és uraim, ez az a jelenség, amikor valaki annyira nem ért valamit, hogy kérdezni sem tud értelmesen. :(

> maga a css, php kódok vagy a php fájlok elérése is adatbázisban van tárolva, ez a része már érdekesebb.
> Van egy index.php fájl, [...] és [...] lekérdezi az index.php tartalmát.
> számít az is, hogy mennyire dinamikus weboldalt akarunk készíteni
> Adatbázisban tároltok például php kódokat, amit majd szükség esetén futtatni fog a weboldal?

Őszintén szólva most azt sem tudom, hol érdemes elkezdeni magyarázni. :(

:)

Hátőőőőő... Én inkább vékony klienst és tárolt eljárásokat használnék az SQL-ben tárolt keres.php helyett.

De a bejegyzés megmosolyogtatott. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Get dropbox account now!

atomjani, ki kell, hogy ábrándítsalak, de látszik, hogy amatőr vagy. Az igazi profi a site-okról csinál egy adatbázist, hogy az index.php-k se jelenjenek meg fájlrendszer szinten.

(Amúgy viccet félretéve, ha tényleg ilyen perverzióid vannak, nézz utána a FUSE-nak, egy kicsit a Python-nak, ha jól tippelem azzal tényleg meg tudod azt csinálni, hogy index.py se kelljen, csak egy connection handler a mod_python mellé, a fájlok szerkesztését meg tudod oldani egy FUSE fájlrendszerrel [és ha jó a sémád, kapásból tudsz verziózni is, access controlkodni, bár nem/nehezen leszel tranzakcionális]. Na a "Miért üres a dokumentrút?" kérdés után ott már mindenki vakarná a fejét ;) )

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

UUUUU, egy fuse alapú sqlite fs -ért kiált a nép!


// Happy debugging, suckers
#define true (rand() > 10)

http://www.nongnu.org/libsqlfs/

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

NeeeeeeeEeeeeEeeeEee:( megelőztek:(


// Happy debugging, suckers
#define true (rand() > 10)

Az még csak-csak elmegy, hogy egy blogbejegyzést adatbázisban tartunk. De az, hogy az index.php tartalma is ott legyen...
Bár láttam már olyan helyet, ahol a képek egy bináris táblában voltak. Mondanom se kell, kicsi volt az adatbázis.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Én viszonylag nagy adatbázist is láttam, amiben BLOB-okban tároltak képeket. :)
(No nem fotóalbum volt)

És milyen jó is az, amikor a BLOB-szegmenst kell karbantartani (régi szemét kihajítása után szabad helyet csinálni benne...)

Szerencsém volt. Tilos volt törölni belőle ;)

Ha csak fix meretu kepeket lehet feltolteni (vagy az alkalmazas lemeretezi a kepet mielott a db-be kerulne) akkor nem lesz annyira toredezett.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Talalkoztam mar olyan alkalmazassal (enterprise kornyezet persze), ahol az elso loadtest utani debugolas soran derult ki, hogy a fejleszto ugy gondolta, hogy 100+ megabyte-os videok tarolasa az adatbazisban jo otlet.

A fájlrendszer is egyfajta adatbázis... Primitív, de attól még az :-D

Nézd meg az oracle-t kicsit közelebbről! Nekik is vannak ilyen ötleteik, bár attól megkímélt a sors, hogy élőben is látnom kelljen:)

Attól, hogy nem a "szokásos" felállást követik, attól még nem biztos, hogy annyira rossz - nekem volt hozzá szerencsém, és bizony elég jó "fájlrendszert" raktunk össze a BLOB-szegmensben lévő táblákban tárolt mindenféle fájlokra, jogosultságokkal (öröklődés lefelé, egyedi eltérések az öröklött jogoktól plusz/mínusz irányban, keresztirányú kapcsolatok (symlink?) a hierarchiában, stb), feltöltéssel, "mozgatással", törléssel együtt. Annyi volt a gond, hogy sok törlés után a töredezett szabad hely használhatatlan volt, úgyhogy rendszeres (néhány hetente) leállás, dump/restore kellett neki.

Nem azt mondtam, hogy rossz.
Csak miután anno belenéztem a multimédiás témákba az oracle doksiban, valahogy nem sok kedvem volt hozzá, hogy élesben is használni akarjam. ;)

Idézet:
Bár láttam már olyan helyet, ahol a képek egy bináris táblában voltak.

Ennek amúgy vannak szép előnyei is:
* tranzakción belül tudod kezelni a fájlokat is - ha az adatbázison kívül vannak, akkor ugyebár nem
* a mentés egyszerűsödik, egy konzisztens dump az adatbázisról garantáltan konzisztens állapotot fog mutatni (küzdeni lehet olyanokkal, hogy ugyanazon a fájlrendszeren vannak a fájlok és az adatbázis, akkor egy FS-szintű snapshotból is konzisztens lesz, de sok más problémát felvet)
* kapsz egy - mondjuk nem optimális - replikációt, már ha a DBMS tudja (egyébként kellene egyszer replikálni az adatbázist, egyszer a fájlokat, hogy legyen failover, ráadásul mindezt illene tranzakciókkal együtt...)
* ...

Valami nem túl agresszív, de létező cache megoldással* még az overhead is kezelhető lehet...

BlackY
*: így tippre akár működhetne is: egy FUSE fájlrendszer, ami indításkor lefoglal magának valami fix méretű memóriát (pl. 2G), amit cache-re használ, Postgres-ből (később lesz lényeges :) ) benyalja az aktuális könyvtár/fájlszerkezetet és felaggat egy-két notify figyelőt. Ha kap egy fájlnyitás kérést, akkor ha 1) a cache-ben van a fájl, kiszolgálja onnan, ha 2) nincs ott, akkor behúzza a DB-ből. A másik oldalon a Postgres a megfelelő táblákba való INSERT-kor/UPDATE-kor a notify csatornán leszól a fájlrendszernek, hogy változás van, az 1) ha a cache-ben volt a fájl, kidobja onnan és mindentől függetlenül 2) a belső szerkezetét update-li az új fájllal/könyvtárral. És így tranzakciókat is figyelembe veszi a cache.
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

MVC-ről hallottál már?

Pár probléma a 3-as megoldással: feleslegesen terheli az adatbázis szervert, ritkán változó, csak id alapján lekérdezett adatokhoz nem kell adatbázis szerver. Odavág a cache-elésnek, igaz a db tud cachelni, de a php-nak minden esetben "új" lesz a kapott kód.

Azt még el tudom képzelni, hogy deployinghoz használod a db-t, de akkor sem a kódot tárolod a db-ben, legfeljebb az aktuális verzió számát és elérhetőségének címét. De erre vannak sokkal jobb megoldások.

Egyébként a 4-es szint az, hogy tárolt eljárás (vagy pl. oracle xsql + xslt) állítja elő az oldalt. Ennek van egy olyan előnye, hogy nem kell hozzá php. ;)

Igen. Nekem olyan is eszembe jutott, hogy mondjuk van 50 ezer user és mondjuk van 500 fajta kezdőlap nekik, mindegyiknél eltérő php kódokkal.
Azt még meg szokták csinálni, hogy lehet az usereknek kinézetet választani. Nem is feltétlenül a css teljes útvonalát kéri le az adatbázisból, mert a php fájlban szerepelhet weblap.hu/$a.css is. De van hogy saját maga szabhatja be a css fájl beállításait, ilyen a betűméret, háttérszín stb állítása.

......................
Egymás segítésére még: http://pc-kozosseg.com

De ekkor nem magát a CSS-fájlt tárolod adatbázisban, hanem egy-két jellemzőt (pl. betűtípus, méret, szín, stb.), ami alapján mondjuk generálsz egy CSS fájlt. Ha magát a CSS-fájlt tárolnád, akkor mi történik a háttérben, ha a user változtatni akar a jellemzőkön:
- kiolvasod a CSS-fájlt
- feldolgozod a beolvasott CSS fájlt, kiszeded belőle a változtatható jellemzőket
- user megváltoztat egy-két dolgot
- legenerálod a CSS-fájlt az új adatok alapján
- módosítod az adatbázisban

Míg ha adatbázisban tárolod:
- kiolvasod a jellemzőket
- user megváltoztat
- frissíted az adatbázist

Utóbbit egyszerűbbnek gondolom.

Megjelenítésnél a jellemzők tárolásakor egy CSS-generálással lesz több.

Talán ez a jellemzőbb, hogy csak bizonyos paraméterek vannak eltárolva az adatbázisban. Talán én is ezt tenném.
......................
Egymás segítésére még: http://pc-kozosseg.com

Nyugtass meg kérlek, hogy nem az IT szakmában dolgozol.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Pár év múlva abban fog. De jó eséllyel szégyellni fogja ezt a korábbi ötletét (jártunk páran így).

Valahol írta, hogy nem ebből él. Különben meg... én közel harminc évig éltem belőle.

Lehet, hogy még együtt fogunk dolgozni valamilyen projektben.

Egyébként fontosnak tartom tisztában lenni, hogy mire is számíthatok. Az, hogy mi számít jónak és hülyeségnek, azt csak azok tudják, akik tudják, hogy ennek meg annak megvalósítása mivel jár, eredmény szempontjából mi tapasztalható. Ahogy olvasható, van olyan cég, amelyik az adatbázis kezelőt elég durván kihasználja.

......................
Egymás segítésére még: http://pc-kozosseg.com

Igen, van, ahol az "adatbáziskezelőt durván" kihasználják. Ha azt nézzük, az ERP rendszerünk is csak egy Delphis frontend az MSSQL előtt és az egész üzleti logika tárolt eljárásokkal van megoldva, amit a kliens hívogat. Viszont ez egy MSSQL által támogatott út és módszer ellentétben azzal, amit te akarsz. (A nagyobb probléma az, hogy szimplán kijelentetted, hogy "így működik". Nem, nagyon nem így működik).

Viszont azt az apróságot ne felejtsük már el, hogy már csak azért sem igazán jó dolog ész nélkül mindent beömleszteni a DB-be, mert igen hamar meg tudja ölni a skálázódást és a teljesítményt. Gondolj bele, kell 100 fájl a DB-ből, az +100 query. Oké, egyszerű queryk, de minek, főleg, mikor létezik file cache?

Ha meg együtt dolgoznánk - vagy valamely kollégám csinálna hasonlót, - az tuti, hogy nem tartana sokáig. Vagy azért, mert rajtam múlik és szét fogok csapni a lovak között, vagy azért, mert nem rajtam múlik és azt mondom, hogy szívjon egy ilyen gányolmánnyal az, akinek hat anyja van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egy szóban ki tudom fejezni, mi ezzel a probléma: redundancia. A. Kisebbik gond az, hogy feleslegesen tárolod le ugyanazt n-szer. A nagyobbik, hogy mit csinálsz, ha változik a site layoutja?

Már mi a francért lenne?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"A mai dinamikus weboldalak általában úgy működnek, hogy van írva index.php..." - Szerencsére ez erősen túlzó általánosítás.

Hol van nagyz, amikor szükség van rá? :-)

+1.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem ír, mert tisztában van saját nagyságával...

:)

A 3. szinten emlitett CMS(szeru !@##$) dolgot hasznalok most napi szinten: https://www.youtube.com/watch?v=Afv_CjEmHXU

--
x-plane :: hu

"A mai dinamikus weboldalak általában úgy működnek [...]"

http://i1254.photobucket.com/albums/hh609/Spray_N_Pray1/No-meme-rage-face.jpg

(Off: Még hogy nem kell kép link...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1

Kérlek menj inkább péknek.

--
deejayy DOT hu

Verziókezelés miatt eleve nem jó ötlet, az fájlrendszeren működik a legjobban, ráadásul sokszor pont az van, hogy a rendszer megvan, csak cserélgetjük alatta a db-t, akkor a rendszer legyen már egyszerű forráskód fájlrendszeren, ne kelljen már pár bash alapparancson kívül semmi a beüzemeléséhez.

Amit fentebb említettek, hogy PL/SQL blokkokat használunk PHP helyett outputfinomításra az meg lehet picit még javítana is a performance-on, de messze nem annyit, amennyivel olcsóbb munkaórákat tekintve PHP programozókat megkérni, hogy dolgozzanak ennél sokkal olvashatóbb és megszokottabb módon struktúrált kódon.

Szóval neked mint keződnek azt javasolnám:
a forráskód legyen egyszerű mappaszerkezet, és adatbázisban csak azt tárold, ami amolyan "modellezhető adat" (táblák azonosítható sorral, semmi más, pl. userek, blogpostok, kommentek, etc.).

Később majd előkerül életedben valahol az MVC (model, view, controller), ott fogod majd megérteni, hogy a DB-be mi való, és nyilván pont ugyanazokhoz kell majd model class is.

Édes istenem... De most komolyan pajtás, itt vagy HUP-on több mint 8 éve, ebből arra lehet következtetni, hogy nem vagy zöldfülű vagy, mégis olyan sületlenségeket _állítasz_, aminek köze nincs a valósághoz, pláne nem a profizmushoz.
--
http://envo.it

Nem látott még IAS-t. Se. :-P

Vagy vagy, vagy... Leginkább. De inkább nem.
--
http://envo.it