ugrás a tartalomhoz

'--disable-pdo'

s_volenszki · 2008. Okt. 9. (Cs), 19.15
Sziasztok!

Ha ezt mondja a szerverem '--disable-pdo' phpinfo()-ra configure command-ban akkor van valami esélyem PDO-t használni?
‹ PHP file kitömörítés php mail fuggveny ›
 ■
1

dl()

janoszen · 2008. Okt. 10. (P), 09.41
Max ha dl()-lel betöltöd arra a szerverre forgatott PDO extensiont, de igazság szerint valószínűleg nagyságrendekkel több szívás mint nem használni, ha egyáltalán lehetséges. Megoldás:

- Írd át pl MySQLi-re (ugye, el van fedve az alkalmazásodban az adatbázis használata?)
- Kérd meg a szolgáltatódat hogy tegyen föl PDO-t.
- Keress egy másik szolgáltatót, ahol van PDO.
- Üzemeltess saját szervert.
2

Azt nem tudom konkrétan mit jelent...

s_volenszki · 2008. Okt. 10. (P), 21.13
...hogy el van fedve, de az adatok "szinte minden esetben" tömbben mozognak az alkalmazás és az adatbázis között, így ha az elfedés ezt jelenti, akkor igen, nekem teljesen mindegy, hogy a tömböt milyen adatbázis motorból, milyen absztrakciós réteg szedi ki, a lényeg, hogy minden index stimmeljen a tömbben.

Megnézem ezt a dl()-t, köszönöm!

Egyébként tudsz javasolni jó dokumentációval rendelkező, olyan könnyen értelmezhető adatbázis absztrakciós réteget mint a PDO? Nincsenek nagy igények, csak a tranzakció kezelés.
3

Absztrakció

janoszen · 2008. Okt. 10. (P), 23.32
Saját PHP osztályok, amik elfedik a PDO/MySQLi/stb funkcionalitását ezzel egy felületet biztosítva a lekérdezésnek. Ennél több nagyon kevés esetben kell. Azon middleware-k, amik teljesen elfedik az SQL szervert, web esetén nem nagyon működnek, hiszen tizedmásodpercekre optimalizálsz.

Szerintem, azon erölködni hogy valami MySQL-en és PostgreSQL-en is működjön és mindez automágikusan történjen sok fájdalom, lassúság és szenvedés okozója lesz. (Hacsak nem annyira egyszerű alkalmazást gyártasz hogy a queryk mindegyiken működnek.)
4

Ne optimalizálj

tolmi · 2008. Okt. 11. (Szo), 10.49
Javaslom neked hogy ne optimalizálj, inkább írj tisztességes kódot. Ha már sikerült tisztességes kódot írni, akkor el lehet kezdeni optimalizálni és mérlegelni hogy megéri-e.
5

Optimalizáció vs hacks

janoszen · 2008. Okt. 13. (H), 08.40
Mondok egy példát, amire nemrég szükségem volt. Full join MySQL alatt. Meg lehet oldani egy UNION-nal. Elvárnád, hogy SQL-ben működjön, de mégsem működik. Innentől kezdve, ha egy absztrakciós réteg ezeket az apró de bosszantó különbségeket elfedi, akkor azt valószínűleg sok többé-kevésbé bonyolult hackkel teszi.

Ezzel két probléma van. Az egyik, hogy adott esetben lassú lehet. Ez nem lenne probléma, mert a vas köztudomásúlag olcsóbb, mint az ember (bár amikor realtime query hegesztés van, nem kevés cycle tud elmenni). Arról nem is beszélve, hogy egy kicsit távolabbról nézve egy bonyolult kódot - application szerver hiányában - minden egyes lekérdezésnél le kell fordítani, le kell futtatni.

A sokkal nagyobb probléma, hogy ezek a hackek egészen változatos szituációkban nem fognak működni. Egész egyszerűen azért, mert minden szituációra gondolni egyszerűen képtelenség, főleg egy ennyire széles területen.

Összefoglalva: nem véletlenül megy el a PHP-s világ az egyszerűbb, laposabb architektúrák felé (nyers PHP-s templatezés, egyszerű absztrakciós rétegek). Lehet architekturális kolosszusokat építeni de csak akkor, amikor tényleg szükség van rá. Elég nagynak érzem a valószínűségét, hogy s_volenszki-nek nem lesz szüksége egy nagy és mindent elfedő architektúrára. Az egyszerű, kicsi és csak szükség szerint absztrahált rendszer valószínűleg kevesebb fejfájást fog okozni.