Administrace komentářů

Souhlasím s tím, že absence dobrého IDE dělá vbývoj dosti problematický. Jenže na druhou stranu některé věci jsou bez nich neřešitelné. Např. materializované pohledy atd... Protože, buďto použiješ nějaký ORM model, který se o to bude starat. Jenže pak můžeš zahodit všechny vymoženosti datbází a optimalizace z nich plynoucí a výkon jde do kopru. To pak už je skoro lepší využáít NoSQL.

Anebo používáš SQL +- přímo. Pak ale zas místo jednoho kódu ho děláš na X různých místech a riskuješ, že ho X+1 místě zapomeneš.

Píšeš využívat cizí klíče? A jak to uděláš, když chceš při smazání nějakého podřízeného záznamu něco např. zapsat do logu?? Buď skončíš s cizíma klíčema na aplikační úrovni, se všema problémama, který to nese, nebo naopak s kódem v DB.

Co se týče zachytávání DB výjimek, tak pokud máš dobře navržený střeva, tak se neliší od zachytávání programátorských výjimek. Co se týče deadlocků, tak rozumnej kód deadlock nezpůsobí. Max co se povede je nekonečná procedura, ale o co je složitější zabít thread v db než zabít proces v OS?

Samozřejmě, mít rozdělenej kód v DB a v aplikaci je problém. Chce to dobrou analýzu a jasný kritérium, co bude v DB a co bude v aplikaci, to je asi největší problém DB programování. Mít vše v db to taky zcela neřeší.

Lazení v triggerech je sice za trest, ale ono ani PHP se nijak extra dobře neladí. Sice existují debuggery, ale vzhledem k tomu, že webové aplikace jsou typu akce - reakce, tak se stejně velmi často ladí pomocí echa. A to jdou trigerry ladit úplně stejně. Pokud máš trigerrový kód "testable", tak se testuje v podstatě stejně dobře jako v db a ladění není tak strašné. Problém psaní v databázi spočívá hlavně v tom, udržet štábní kulturu.