[NDBT] Co dělá SqlPreprocesor a proč ničí prepared statement?
- Jan Tvrdík
- Nette guru | 2595
přišel jsem na to, že to může nepoužívání prepared statements
Jak jsi na to přišel? Skutečné prepared statements jsou v reálu skoro vždycky pomalejší.
- David Grudl
- Nette Core | 8285
Vycházím z toho, že prepared statements nemají pozitivní vliv na rychlost – to samozřejmě už nemusí pro některé databáze platit a pak se s tím může něco dělat.
Vlastně NDB nepoužívá prepared statements u krátkých řetězců, booleanů a integerů kvůli čitelnosti vygenerovaných SQL příkazů, ale to už dnes řeší panel v Tracy po svém a dá se to změnit velice jednoduše.
U typů float a datetime by to vyžadovalo trošku výzkum, jak je správně předávat, např. u microsoftích databází.
Samotné PDO v případě MySQL používá defaultně
PDO::ATTR_EMULATE_PREPARES, které je třeba vypnout, aby se
prepared statements vůbec používaly, jenže to způsobí BC break, protože
některé příkazy jako třeba USE dbname nebo BEGIN
se pak musí volat funkcí PDO::exec(), kterou NDB
nepoužívá.
V případě PostreSQL by došlo k BC breaku třeba při
$db->fetch('SELECT ?', 123), použití prepared statements by
vedlo k chybě could not determine data type of parameter.
- CZechBoY
- Člen | 3608
Diky za objasneni.
Nevim proc ale v oraclu mi prepared statements trvaji o 300ms mene nez
v opacnem pripade. Asi si to cachne plan nebo neco takovyho.
Preprocesor jsem si prepsal aby vracel otazniky i pro pole a funguje to
dobre.
Chapu ze nekonzistentni chovani db serveru se da takhle resit, ale bylo by dobre
mit moznost takove chovani vypnout treba v driveru.
- David Grudl
- Nette Core | 8285
Kdybys pripravil testovaci prostredi pro Oracle, neco jako je Travis nebo Appveyor, dalo by se s tim asi neco udelat.