Administrace komentářů

Materializované pohledy jsou buď triviální SELECT, a pak je nahradím normálním pohledem, nebo jsou výsledkem komplikované operace, a pak typicky nechci aby se ta operace prováděla při každé změně rodičovských tabulek. Samozřejmě by šlo najít nějaký protipříklad, ale zatím jsem to potřeboval jednou (statistika nad 10M+ řádky), a tam jsem použil tabulku co se jednou za čas přepočítá. A i tam by to šlo řešit v aplikaci stejně dobře jako v triggeru, kdybych chtěl. Je to tím že do dané tabulky zapisuje jediná funkce, kde se dají dělat i tyhle výpočty.

NoSQL je dobrá alternativa, ale migroval bych na ni až v momentě, kdy MySQL přestane stíhat. Zatím pořád sype data rychleji než několik Firefoxů najednou stíhá renderovat..

SQL používám přímo, ale samozřejmě všechny dotazy jsou v jednom samostatném modulu. Takže redundance se nekoná a v případě změny databáze změním jeden soubor.

Když chci logovat změny, prostě zavolám logovací funkci z funkce co mění data. Dá se namítnout, že člověk co si pustí SQL prompt může mazat bez logování, ale to mě zatím netrápilo. Takhle můžu logovat co chci a kde chci, nejen to co proteče až do konkrétního triggeru. Jaké jsou ty další problémy?

Zachytávání vyjímek se možná neliší od toho v aplikaci, ale proč to dělat na dvou místech? Dá mi to něco podstatného, když to udělám i v databázi?

To že rozumný kód nezpůsobí deadlock je pěkná teorie, jen bych rád viděl jak dlouho člověku vydrží v praxi. A nemusí být ani prase - stačí zapomenout explicitní lock na některé z tabulek na začátku transakce, a pak si naběhnout na deadlock přes implicitní zámky. Zabít thread se sice dá, ale uživatelé nejsou moc rádi, když kvůli deadlocku lehne celý systém.

S nutností štábní kultury se nedá než souhlasit. PHP taky ladím přes echo a print_r.