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

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?

( Mcsiv v | 2014. 03. 06., cs – 16:38 )

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

( Replaced | 2014. 03. 06., cs – 16:52 )

velemeny: lol

--
NetBSD - Simplicity is prerequisite for reliability

( uzsolt v | 2014. 03. 06., cs – 17:10 )

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 :)

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.

( fhuse | 2014. 03. 06., cs – 17:31 )

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. ;)

( winben | 2014. 03. 06., cs – 19:09 )

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

( gelei v | 2014. 03. 06., cs – 19:17 )

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. :(

( GerzSonka | 2014. 03. 06., cs – 19:27 )

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!

( SzBlackY | 2014. 03. 06., cs – 19:39 )

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)

( lajos22 | 2014. 03. 06., cs – 20:38 )

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

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.

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)

( BaT | 2014. 03. 06., cs – 21:50 )

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.

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™

( zeller | 2014. 03. 07., p – 09:34 )

"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.

( wachag | 2014. 03. 07., p – 11:12 )

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

( carlcolt | 2014. 03. 09., v – 21:31 )

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.

( zsoc | 2014. 03. 11., k – 17:33 )

É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