MySql adatbázis műveltetés JavaScript-tel
Sziasztok!
A napokban az ebben a topic-ban lefolytatott diskurzus eredménye képpen felvetettük a lehetőségét egy kliens oldali eljárás gyűjteményre és egy szerver oldali php osztályra, ami együtműködve lehetővé tenné a mysql adatbázis műveltetést szerver oldali programozási ismeretek nélkül.
Elég sokat gondolkoztam ezen a gondolaton, és én is oda jutottam, hogy ha megfelelően konfigurálva van egy adatbázis műveltető php osztály, akkor kliens oldalról tulajdonképpen minden elvégeztethető javascript-tel. Továbbá ha az adatbázis kapcsolódásához szükséges információk szerver oldalon vannak include-olva, akkor elképzelhető nem csak read only módban az alkalmazás.
Azomban mielőtt 0-ák és 1-ek millióit állítanánk csatarendbe, gondolkozzunk el egy ilyen rendszer gyakorlati alkalmazhatóságán.
Előnyök és hátrányok kendőzetlenül.
s_volenszki
■ A napokban az ebben a topic-ban lefolytatott diskurzus eredménye képpen felvetettük a lehetőségét egy kliens oldali eljárás gyűjteményre és egy szerver oldali php osztályra, ami együtműködve lehetővé tenné a mysql adatbázis műveltetést szerver oldali programozási ismeretek nélkül.
Elég sokat gondolkoztam ezen a gondolaton, és én is oda jutottam, hogy ha megfelelően konfigurálva van egy adatbázis műveltető php osztály, akkor kliens oldalról tulajdonképpen minden elvégeztethető javascript-tel. Továbbá ha az adatbázis kapcsolódásához szükséges információk szerver oldalon vannak include-olva, akkor elképzelhető nem csak read only módban az alkalmazás.
Azomban mielőtt 0-ák és 1-ek millióit állítanánk csatarendbe, gondolkozzunk el egy ilyen rendszer gyakorlati alkalmazhatóságán.
Előnyök és hátrányok kendőzetlenül.
s_volenszki
AJAX alkalmazás
Ami már korábban elmondtam, szerintem, a tárol a eljárások használata lesz a megoldás de még így is kérdéses, hogy legalább valamiféle autentikációt/session kezelést nem kellene-e megvalósítani.
Szerintem, ez úgy működhez, hogy a PHP annyit csinál, hogy kiszolgálja az adatbázis fele menő kéréseket és a sessionöket kezeli. Ha adatbázisnak tárolt eljárásba megy a kérés, akkor plusz egy paraméterként csatolja a belépett felhasználó nevét.
Ezzel egyben meg is van oldva a gyakran előkerülő login-probléma. Ezek után már csak SQL-ben és JS-ben kell szorgalmasan programozni. Aki akarja, az meg tovább fejleszti a dolgot.
ui. végre egy agysejt-mozgató téma... :)
ördög ügyvédje leszek most :)
Azonban, ahol én problémákat látok:
- a flood-kontroll mindenképpen szerveroldalon kell legyen (vagy PHP vagy tárolt eljárásban), mivel a JS bármikor megnézhető, egy kezdő javascriptes is képes visszadebugolni a forgalmat, elég egy Firebug hozzá
- a tárolt eljárások eléggé DB specifikusak
- a PHP-t (vagy egyáltalán a szerveroldali nyelvet) éppen az előző pont miatt érdemes legtöbbször közbeszúrni
- ha ennyire vékony lesz a PHP-s réteg, akkor érdemes elgondolkodni valami gyorsabb, PHP-nál kisebb memóriaigényű szerveroldali technikán (pl.: egy C library, apache modulként letolja a dolgot, nagyságrendekkel gyorsabban, s mivel nincs PHP-s logika, csak interface, ezt meg lehet csinálni C-ben is).
- kérdés: mennyiben különbözik ez mondjuk attól, amit pl. a xajax, vagy amit a protojax valósít meg? azon túl, hogy ezek vastagabb PHP-s réteget is engednek?
- mennyiben nyújtana ez többet, mint egy egyszerű php connect-query-json_encode-exit file?
ps.: nem kötekedés, csak ezek jutottak eszembe első körben :)
Miért jó ez?
Gyakorlati alkalmazás.
Továbbá én is úgy gondolom, hogy a témában szükséges a kliens szerver modell ismerete! De mégis! Lehetnek olyan alkalmazások, ahol nem lenne szükséges a szerver oldali programozás tudás, de mégis van valamilyen irányított adatforgalom?
Erősen agyalok egy minta folyamaton, de mindíg oda jutok, hogy kizárólag alkalmazás specifikusan venném hasznát egy ilyen rendszernek, viszont onnantól kezdve meg nincs jelentősége a rugalmasságának.
Használtunk hasonlót
1. Mivel minden lekérdezést nem volt praktikus JS oldalra pakolni, ezért vegyesen fordultak elő szerver és kliens oldalon, ami karbantartás szempontjából egyre viccesebb lett.
2. Jogosultságkezelés gyakorlatilag csak SQL szerver szinten oldható meg, ami nehézkessé tesz a telepítést, és nem is elég rugalmas (pl. rekord szintű jogok esetén bukta van)
Szóvan részemről az általános, JS oldali SQL matatás kilőve.
Jogok
A másik: én SQL szinten oldottam meg a jogosultság kezelést már csak azért is, mert az volt az első lépcső. Már SQL-en ne lehessen túljutni...
Ami a C libet illeti, lehetne, de hány olyan szervert ismersz, ahol lehet ilyesmit futtatni?
Zend_Db_Table + js
üdv t
Necces
Más:
Ha muszály kliens oldalon csinálni (néha lehet, hogy elkerülhetetlen, a php oldal vékonyan tartásához), akkor egy js-től különböző nyelvvel lehet hogy jobb eredményt kapunk, amit a szerver (is) parszol. Így az adat útja kliens oldali program -> szerver értelmezi, végrehajtja -> kliens oldal is értelmez, adatot megjelenít. Vagyis kliens oldalon megírva, egy helyen átlátható kódot kapnánk, a php réteg pedig tényleg csak az értelmezés egy részét végzi. Vagy apacs modul, és akkor még jobb. Meg js értelmező helyett mozilla xpi (ie nem igazi brózer, bár activeX-szel ar is szép megoldás lehetne). szépen elkalandoztam a lényegtől, de végülis ez is megoldja a szerver <-> kliens között különdbégek feloldását...