Dotaz: Before update trigger v mysql - jak a "kdy" se provede

[crit.ik]

Zdravím. Mám dvě innodb tabulky první(id, sloupec, ...), druhá(mID, kID, kontrolovany). IDčka v druhé tabulce jsou cizí klíče na první. Napsal jsem si before update trigger na první tabulku tak, že pokud se něco změní určitým způsobem (OLD.sloupec = 'neco' a NEW.sloupec = 'necodalsi'), pak se zaktualizuje sloupec kontrolovany v druhé tabulce. Pokud to dobře chápu, tak musím používat OLD.id pro hledání záznamů v druhé tabulce, protože i kdybych změnil id, tak se to projeví až po before update triggeru(??) kaskádovým zaktualizováním IDček v druhé tabulce. Je to tak? Jenže co když se něco pokazí a mezitím už se zaktualizovala druhá tabulka? Provede se rollback nebo se to vůbec neprovádí v transakci?

Odpovědi

[l0gik]

ON UPDATE CASCADE závislý sloupec by se měl změnit po before ale před after triggerem.

Co myslíš tím něco pokazí? Pokud bude do tý tabulky zapisovat nějaká jiná transakce? V tom případě záleží na transaction isolation, aby to fungovalo tak, jak chceš, tak musíš mít nejmíň repeatable read. V opačnym případě opravdu můžeš měnit něco, co už je jinak.

Mysql co vím řeší tydle úrovně izolace zámkama, takže selhání transakce by hrozit nemělo. Ale 100pro jistej si nejsem, jen 99.

---

Jinak - before trigger by měl spíš sloužit k validaci dat, případně změnán ve vkládaných datech, úprava okolních tabulek IMHO patří do after triggeru: tedy do okamžiku, kdy již je jasné, jak vkládaná data vypadají. V opačném případě by se teoreticky mohlo stát, že se data před uložením do tabulky ještě nějak změní a tedy okolní tabulky změníš špatně.

I když to u mysql s jejím jediným triggerem tak nehrozí (tam může nastat změna leda díky default hodnotám sloupců), ale imho to patří k "programátorské kultuře".

[crit.ik]

Tím pokazí myslím třeba to, že z nějakého důvodu havaruje server nebo mysql zjistí, že z nějakého důvodu dotaz nelze dokončit. Úroveň izolace mám REPEATABLE READ, u innodb se každý dotaz provádí jako samostatná transakce - to vím, jen mi nebylo jasný, kde transakce začíná a skončí, tzn. zda se do ní zahrnuje celý trigger? Jsem nucený používat before trigger, protože pouze ten mi umožní zjistit stav starý (OLD.) a nový (NEW.) a ty porovnat - právě proto se tady ptám na ty transakce, aby se nestalo, že se provede celý trigger, ale potom to skončí a nevrátí se změny. Mimochodem jsem zjistil, že v mysql nefunguje ON UPDATE CASCADE pro více sloupců odkazujících na nějakého stejného rodiče (ID1 cizím klíčem ID, ID2 cizím klíčem ID) - tedy funguje pouze tehdy pokud se dané id nenachází v obou sloupcích (ID1 a ID2). To je standardní "vlastnost" relačních databází nebo jen berlička mysql?

[okbob]

správně by se měla transakce uzavírat až po provedení after triggeru, tj ještě v after triggeru mohu vyvolat výjimku a provede se rollback - jinak fakt nevím, jak to je v MySQL, tak i v before triggeru mám oba stavy NEW a OLD - pouze NEW ještě není zapsán do db.

[l0gik]

transakce začíná v okamžiku, kdy voláš begin a končí když voláš commit. Popř. začátkem a koncem dotazu v autocommit mode (což je používat zvrhlost).

Pokud dotaz zhavaruje, tak se prostě celej zahodí (rollback). Pokud spoléháš na transakce, rozhodně ale používej BEGIN a END.

Mysql neumí v after triggeru old? Hmmm.... Nechceš místo řešení x problémů se společným jmenovatelem (mysql) změnit databázi?

Více klíčů je evidentně mysql fíčura, v databázích to funguje.

[crit.ik]

Upřímně řečeno se mi chce nejraději zdrhnout k postgresql, protože tam bych toho nemusel ani tolik měnit na straně klienta(v aplikaci) kvůli podobné syntaxi, ale tuhle databázi vůbec neznám, takže by byl asi problém převádět celé schéma do postgresql.

[l0gik]

moc se toho měnit nemusí, autoincrement field na serial a pár dalších drobností. IMHO to budeš mít rychlejc, než neustálý řešení toho, co v mysql nefunguje, popř. se to chová jinak, nežs čekal apod...

[crit.ik]

Tak jsem to hloubkově prozkoumal a zjistil jsem, že bych musel změnit úplně všechno. Např. všude kde mám unsigned int bych musel vytvořit triggery, které by při záporném čísle nastavily 0 (nikoliv check který by to zablokoval), musel bych přepsat aplikaci aby počítala s tím, že v postgresu jsou všechny (var)chary case sensitive (lower mi bohužel nestačí) ... No práce tak na týden. Raději jsem přidal do tabulky další IDčko, na kterém jsou další tabulky (respektive jejich sloupce) závislé a nastavil jsem ON UPDATE RESTRICT a změnu "dílčích" tabulek budu provádět v transakci v before triggeru.

[okbob]

Asi už jste našel řešení, tak spíš přidám informaci pro ostatní - v PostgreSQL contrib modulech je modul "citext" - ktery přidává podporu pro typ citext, což case insensitive text, a podporu pro unsigned int lze dohledat na pgfoundry - i když dost možná, že pro zápornou hodnotu hodí exception - tyhle nelogičnosti MySQL nikdo neimplementuje.

[Šangala]

Už je to tu zas , „ty nelogičnosti“ s unsigned typy, jsou více než logické, jednou je to třeba 2^32 tak proč to nevyužít - nepotřebuji dvakrát tak velká data. To, že některé jazyky na to kašlou je jejich mínus, ale implementace základních datových typů by měla být standard i ve variantě unsigned (měl jsem sen… ).
Toto je jedno obrovské plus MySQL, které bohužel určitě časem zmízí…

[okbob]

nelogičností jsem nemyslel unsigned typ - ale fakt, že při zadání záporného čísla se nevyhodí výjimka.

mysql> select cast(-1 as unsigned);
+----------------------+
| cast(-1 as unsigned) |
+----------------------+
| 18446744073709551615 |
+----------------------+
1 row in set (0.00 sec)

[Šangala]

Aha, tak sorry.
No o tom by bylo možné vést debatu co to má udělat, takto se to chová, dle mého, jak bych očekával - já bych neměnil.
A mimo jiné je to reverzibilní.
viz:

select cast(18446744073709551615 as signed );

[okbob]

takové chování chápu v nízkoúrovňovém jazyku jako je C. V SQL to ale nemá co dělat - pokud datový typ nedokáže uložit data bez zkreslení, tak má vyhodit výjimku. Je to stejná prasárna, jako tichý ořez varcharu nebo vložení datumu 0000-00-00 - tomu se říká doménová integrita.

[Šangala]

Jak říkám, je to o úhlu pohledu, já naopak vítám, že se to tak chová - je to prostě shodné/obvyklé chování jak jinde.
Co se týče ostatního, to přece záleží na Vás jestli se to tak bude chovat, je to o nastavení prostředí (prostředí máte pod kontrolou).
Nastavením v sql_mode na STRICT_ALL_TABLES, Vám to řetězec neořízne.
Nastavením v sql_mode na NO_ZERO_IN_DATE a NO_ZERO_DATE žádné 0000-00-00 nebudou.
Pokud nemáte rád „jiné“ chování, tak použijete zkráceně sql_mode = TRADITIONAL.
Osobně pro web obvykle dám SET @@session.sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' (+ vypnu autocommit) - a to mně stačí a vyhovuje, ale pokud někomu vyhovuje něco jiného, nebo nechce [využívat tyto výhody || být naštván těmito odlišnostmi], tak volba TRADITIONAL je jeho.
PS: „Doménová integrita“ je obecný pojem a jen takto neříká nic o tom jestli je to špatně nebo dobře.

[okbob]

Ty konfigurační proměnné jsou v MySQL proto, že Monty vůbec nechápal SQL a vlastně ani se nesnažil napsat SQL databázi - jen vylepšoval jednu knihovnu, psal ji v C a snažil se ji napasovat co nejvíc na C. Později už jim bylo stydno, tak tam dopsali možnost by se MySQL alespoň částečně přibližovala standardu.

[Šangala]

Volby jsou prostě na nastavení prostředí, má je každá databáze (v PostgeSQL je to, mimo jiné, PGOPTIONS). A je zodpovědností administrátora jak nastaví „default“ a zodpovědností „programátora“ jestli se s tím smíří nebo si to nastaví jinak.
PS: Chtělo by to více lidí co „vůbec nechápou SQL“, aby vznikly lepší úložné systémy . Nikdy se nic neposune dál, pokud se nepokoušíte odlišit….

[okbob]

přijde na to, zda-li se o evoluci snaží bastlíř nebo profík. Monty je spíš bastlíř :)

[okbob]

a abych jen nekritizoval - je to úspěšný bastlíř - vydělal milióny a dodal internetu produkt, který internet potřeboval, kdy byla větší potřeba rychlé a nenáročné databáze - bez ohledu na integritu dat. Bez MySQL by internet, tak jak ho známe dnes neexistoval - nebo by byl pár let pozadu.

[l0gik]

Shodné chování jako jinde??? - Že to některé vlastnosti inicializuje a některé ne? - Ve všech jiných jazycích buď integer overflow hodí výjimku, nebo tiše "přeteče". Kde jinde se při vstupu příliš malé/velké hodnoty nastaví hodnota na MIN/MAX? atd... Kdyby se MySQL chovala jako jinde, jenže ona zavádí nové vzorce chování, naprosto navíc nekonzistetní a často nelogické, a tváří se, jako že jsou normální. A jak je vidět, občas o tom i lidi přesvědčí...

Ano - některé vlastnosti jde přenastavit. Jenže to řeší problém jen napůl: každý si zvykne na "jinou mysql" a díky tomu vznikají neportability i mezi mysql-mysql. O portabilitě na jiné databáze, když mysql přestane stačit (jako třeba v tomto případě) nemluvě). Navíc volby neodstraňují všechny nelogičnosti, co v mysql jsou (proč se trigger nespouští při cascaded updates? proč nejdou dva FK z jedné tabulky na stejný sloupec, proč....)

PS: Ad domain integrity. Domain integrity znamená "co mohu do daného sloupce dát". Ostatní hodnoty mají být odmítnuty. A naprosto nechápu, proč některé (a pouze některé) z možných chybných vstupních dat jsou místo odmítnutí převedeny na něco jiného. Zdali je to chyba v doménové integritě nebo v něčem jiném je otázka diskuse, v každém případě je to nekonzistence a každá nekonzistence je špatně, protože zvyšuje pravděpodobnost chyby.

[Šangala]

Je to jako při přetypování zápisu (céčkovému):

long i = -1;
unsigned long ui = (unsigned long) i;

nebo-li C++:

long i = -1;
unsigned long ui = static_cast<unsigned long>(i);

Ad. každý si zvykne na "jinou mysql"

ten problém je jinde, ne v tom že každá je jiná (to bývá i jiný typ engine nastavený různě), problém je v tom, že programátor si má vyžádat nastavení prostředí, pokud to umožňuje a to buď konfigurací od administrátora nebo, a to je tento případ, nastaví si je sám. Pokud se tento bod ignoruje, což je právě tou častou příčinou, tak je jasné, že to nebude fungovat. Jak jsem již naznačil to není jen problém MySQL - jen se u ní nejčastěji řeší, protože něco co by mohlo být považováno jako standard (rozuměj standard nastavení MySQL), je moc „volný“ a neodpovídá „striktnímu“ nastavení, „chcete-li SQL standardu“, takže to bývá nastaveno různě, ale znovu „každá aplikace si může nastavit toto chování a měla by to dělat, má-li být přenositelná“.

Na otázky proč?, mám odpověď „prostě je to tak“, takových otázek, s různých pohledů „nelogičností“ lze najít u čehokoliv a i u jiných SQL engine.
proč nejdou dva FK z jedné tabulky na stejný sloupec - proč by nešly?

Ad. PS: Pokud jste tyto hodnoty povolil, tak je považujete za validní a konzistentní, nikoliv chybné. A povolil jste je právě tím, že jste si nenastavil chování prostředí takové, aby odpovídalo vaší představě. Pokud administrátor MySQL nastaví kompatibilitu (s čímkoliv chcete) na 0 (což je default) a vy si ji nepřestavíte, tak prostě to berete jako vlastnost a akceptujete ji ze všemi nastaveními.

[l0gik]

Tak si zkus do unsigned políčka vložit zápornou hodnotu. Vloží se Ti nula. Takhle jak píšeš se v MySQL chovaj aritmetický operace a explicitní konverze, nikoli ale implicitní konverze. To je právě jedna z věcí, která se mysql vyčítá: jednou se chová tak, jednou jinak.

S těma dvěma foreign key v jedný tabulce máš pravdu, to už jde, už nejde akorát když jsou dva foreign key na stejném sloupci, což je prasečina. Ona se mysql pomalu těch největších hrůz zbavuje, ale furt jich zůstává dost (např. triggery x cascaded updates, což činí jednu z těch dvou věcí nepoužitelnou).

Jinak ano, nelogičnosti lze najít u každé db. U mysql je jich ale řádově více než u Mysql. Schválně, kolik jich najdeš např. u postgresu. Sám když jsem po mnoha letech přešel z mysql na postgresql, tak mě začaly dělat problémy až takový věci, jako multitable updatable views a podobný advanced topic (pro něž navíc většinou neexistuje standard). Oproti tomu i po deseti letech s mysql mě mysql čas od času překvapí, co mysql dělá jinak popř. co v ní nejde.

Pokud musím před použitím produktu prolézt manuály a zjistit, kde všude se ve standardním nastavení odchyluje od standardu a musím ho přenastavit, popř. když přenastavit nelze se daným konstruktům vyhnout, považuji produkt za špatný. Protože konkurenční produkty toto nevyžadují: v standardním nastavení se chovají předvídatelně.

[Šangala]

Implicitní a explicitní konverze se může lišit, je to obvykle nepříjemné (a je dobré ji raději v takovýchto případech uvést explicitně aby bylo jasno). Nicméně, budu se opakovat je to stálně o nastavení prostředí smiřte se s tím, ne-nastavení prostředí v MySQL obvykle znamená (protože admini to tak nechávají) velkou volnost a spousta error-ů jsou jen warning-y. Asi proto, že to MySQL byla dělána jako jednoduchý úložný systém pro web a tento default jí zůstal. „Mně to -1 do unsigned pole nevloží“ .

Pro mně je „nelogičnost“ (spíše bych to nazval nedostatkem):
(Obtížně se mi takové věci definují, prostě to beru jak to je, takže sem vypíši věci, u kterých nemám jasno jak se s nimi vypořádat.)

• PostgreSQL standardně nepodporuje unsigned typy
• Nemá něco jako show create table
• U pg_dump při formátu 't' nelze 2× udělat stejný soubor, při nezměněných datech či struktuře.

Oproti tomu i po deseti letech s mysql mě mysql čas od času překvapí,
jen: „¿dělal's někdy s MSSQL?“

Pokud musím před použitím produktu prolézt manuály a zjistit
Toš ale fčul sorry, to je berlička, tak těžké najít to není a obvykle je dobré znát jako první jak se chová prostředí a operátory aby jsi věděl na co si dát bacha, a jak to lze případně nastavit.

MySQL se nikdy nehonosila tím (aspoň o tom nevím), že jede přesně podle standardu (to nejede ani Oracle), na rozdíl od uváděné PostgreSQL, která se ho drží jako klíště a chlubí se tím. MySQL v minulosti byla jediná volně použitelná DB a v drobných web aplikacích okamžitě našla místo a má ho tam doposud, protože (jejda, to se nebude líbit) i když je PostgeSql super standard a všechno, teprve v nějaké osmičkové verzi dohnal MySQL v některých oblastech. Prostě MySQL je databáze stejně jako PostgreSQL či MSSQL nebo třeba Firebird, každá je na něco a každa se sem tam chová jinak, než očekáváme, ale obvykle je to naší neznalostí, kdyby byly všechny stejné stačí jedna.

[l0gik]

Co má co společného (ne)smíření se s danou vlastností s tím, jak je daný produkt kvalitní? Ano, já o dané vlastnosti mysql vím a jsem s ní smířen. Ale pokládám ji proto za nepříliš dobrý produkt.

"Je první, znát jak se chová prostředí...". Jak jsem psal, při přechodu na postgresql jsem narozdíl od mysql žádné "seznamování s prostředím" nepotřeboval. Vše (až na hodně advanced topics jako např. chování rules a volatile funkcí) se chovalo tak, jak jsem čekal. Totéž u firebirdu. Tobě možná jsa vychován na mysql nutnost "seznamování s prostředím" připadá normální, mě po létech praxe s jinými DB nikoli. S MSSQL jsem neměl tu čest, ale to, že je jeden produkt špatný ještě neznamená, že nemůže existovat dobrý.

"Mysql se nehonosila tím, že jede dle standardu" - ale to přeci není věc chlubení? Podpora standardů je přeci samozřejmost...

"to nejede ani Oracle" - ty chceš srovnávat odlišnosti Oracle od standardu s odlišností Mysql???

"mysql je databáze stejně jako..." - nesouhlasím. Ano mysql je databáze. Je to ale co se týče standardu i podpory suveréně s odstupem horší databáze než zbylé jmenované. Např. jako jediná nenabízí CTE. Jako jediná nemá použitelné triggery (nelze je používat spolu s referenční integritou, nehledě na omezení jednoho triggeru na tabulku), velmi omezené možnosti co se týče uložených procedur (pouze jedna návratová hodnota) atd... Jako jediná v defaultní konfiguraci mění vkládaná data pod rukama atd....

Asi jediná výraznější výhoda je dostupnost na freehsotinzích a nabídka replikace (ta se ale pomalu dostává i do konkurenčních db). Proto tvrdím, že mysql není dobrá databáze: její negativa pro běžný projekt vysoce převyšují výhody, které má oproti jiným DB. ---

Ad: Tebou uváděné nevýhody, tak žádná mě zatím nikdy nijak neomezila. Např. - unsigned typy: pokud chceš, existuje pro ně extension do postgresu. Naprosto ale nevidím důvod, proč je neimplementovat jako signed + constraint. Bych moh nadávat mysql, že nemá neomezený varchar, spešl formát pro ip adresu, pole atd... Tomu říkám objektivní přístup: omezenost datových typů u mysql nevadí. Ale u postgresql je to chyba... - \d table, popř. pg_dump ti nestačí? Pokud ne, tak např. http://okbob.blogspot.com/2009/12/macros-for-epsql.html, nebo existuje plpgsql implementace... - pg_dump: tak použij jinej formát? Tudle nevýhodu nějak nechápu, pg_dump poskytuje různý formáty, každej má svoje + a -. Proč by museli všechny tydle formáty bejt "stabilní"? Kdyby z pgsql nešlo dostat stabilní výstup, tak bych to chápal, ale takhle?

Tvoje hodnocení postgresu a mysql mi prostě přijde jako naprosto neobjektivní. Dáváš na roveň to, že konkrétní jeden tool z postgresql (kterej ani nemá na mysql protějška) se nechová tak, jakl bys potřeboval s nedodržováním standardů a nefunkčností základních postupů db programování? Srovnáváš to, že místo USINGED INTEGER napíšeš INTEGER CHECK (value > 0) s tím, že ti mysql bez upzornění ořeže stringy a tím zmrší data? Připadá mi to, že to co neumí mysql "je normální, že to db neumí", zatímco pokud má mysql nějakou extension, tak je chyba všech ostatních, pokud ji neimplementují, popř. implementují jinak.

--

Ano, mysql byla v jednu dobu na standardní webové produkty nejlepším nástrojem. Třeba proto, že postgresql byl budován "z gruntu pořádně" a tedy mu trvalo déle, než se dostat do použitelného stavu. V současné době ale prostě postgresql dohnala mysql co se týče použitelnosti, přitom ji ale zůstaly všechny výhody jejího od počátku kvalitního návrhu. Jinými slovy: ano, byla doba, kdy byla mysql použitelnější db. Ta už je ale několik let pryč.

[Šangala]

Jsem tušil, že si to schytám. Nejsa vychován na MySQL (Hů, spíše na Paradoxu a Firebird-u, když to nebyl ještě Firebird - pokud to má být to, s čím jsem přišel do styku první). Nikdy jsem nenapsal nic o tom, že když je jeden produkt špatný, tak by nemohl existovat jiný - lepší. Jen jsem chtěl tím chtěl říct, že překvapení u MySQL nejsou tak nepříjemná jak u MSSQL.
Podpora standardů není samozřejmost, je to vlastnost a každý se na základě toho může rozhodnout, jestli to má použít. Ano chci srovnávat odlišnosti MySQL a Oracle, ale ne konkrétní, jen obecně, protože oddlišnost se nemusí rovnat špatnost.
Možná to někde zavánělo jako hodnocení PostgreSQL, ale neměl jsem to v úmyslu a kdyby měl hodnotil bych pozitivně, je to asi nejlepší DB, která je k dispozici.
To že Tebe neomezily, některé parametry, tak to ještě neznamená, že by nemohli někoho jiného.
Sorry ale co s tou objektivitou, tys mě vyzval, tak jsem odpověděl, úkolem nebylo srovnávat.
Každý nepracuje furt s IP adresami, takže to třeba někomu nechybí, ale chybí mu něco jiného…, nikdy jsem nepotřeboval delší varchar než nějakých 6000 znaků, ale dokážu si představit, že někdo jo (v Mysql bych to dal do xxxxTEXT).

zatímco pokud má mysql nějakou extension, tak je chyba všech ostatních, pokud ji neimplementují, popř. implementují jinak
Nikde jsem nenapsal, že je to chyba, ale je to nedostatek.
Jinak signed/unsigned není jen o tom jestli to může nabývat záporných hodnot (to je prkotina), ale hlavně je to o rozsahu 0 - 2^32-1 - pak je DB zbytečně 2× tak velká protože musím použít 64bit INT a na konec se nevleze výrazně dřív do paměti. Vím, že to většinou nevadí (na 90% aplikací), ale někdy jo DB nejsou jen na IS.
O extension už Vím, nicméně to pak není ve standardní instalaci a je to v důsledku výrazně větší omezení než nastavení prostředí v MySQL.

Nebaví mě vyvracet polopravdy a hájit MySQL neustále proti novým věcem, klidně použiju PostgreSQL stejně jako MySQL. Napsal's to všechno má své ±.


Kdo si to náhodou četl až sem, tak a si vezme jen informaci SET @@session.sql_mode = TRADITIONAL mu usnadní práci v MySQL a vyplatí se na nastavení prostředí se podívat, stojí to jen ½ hodiny.

[l0gik]

Ad standard: podpora standardů je vlastnost veskrze dobrá. Např. proto, že že minimalizuje riziko chyb, protože při přechodu z jiné databáze vše funguje, jak má. Kromě toho to není věc, nad kterou by šlo "máchnout rukou", ukazuje to na kulturu a filosofii vývoje daného produktu. Není náhoda, že v mysql s její podporou standardů spousta věcí "funguje" (tzn. funguje jen za danýách podmínek a s danými omezeními), zatímco v postgresql funguje. (podotýkám, že zdaleka ne vše lze vyřešit konfigurací, např. zmatek kolem datetime typů a jejich defaultních hodnot).

Ano - neexistence unsigned v postgresu je nedostatek. Ano - ale v kolika projektech to vadí. Vzhledem k tomu, že existujou hotový extension, tak kdyby byla po tom typu poptávka, tak už je dávno přidanej. Navíc si troufnu tvrdit, že daleko víc lidí v reálu pracuje s IP adresama, než s datama, který jsou právě velký na signed, ale ještě dost malý na unsigned. Tadle nevýhoda je prostě podle mě naprosto nesouměřitelná s nedostatky mysql (níže). N

Nevím, jestli má další debata cenu, pokud myslíte, že jo, tak bych prosil o vyjádření, jaký důvod by člověk měl k použití mysql místo postgresu. Zatím jste dodal jeden snadno odstranitelný (unsigned int) a jeden, kde jde o styl práce (jestli definici tabulky získam z sql konzole nebo z commandline). Tak by mě zajímalo, jaké jiné důvody by měly být pro použití mysql. Protože pro použití postgresu je jich spousta, namátkou

  - lepší podpora standardů (i po SET @@session.sql_mode = TRADITIONAL)
  - funkčnost triggerů a referenčních integrit
  - funkčnost fulltextu a transakcí
  - podpora CTE 
  - podpora tabulek vracejících procedur
  - podpora funkčních indexů

atd... Řekněme, že jsem v pozici, kdy si vybírám databázi pro svůj nový projekt. Proč bych měl vybrat právě mysql? Důvodů, proč místo ní vzít postgresql jsem uvedl dost.

[Šangala]

Naše debata vznikla tady, kde jsem se Ti jen následně snažil vyvrátit cos napsal. Postupně jsi přidával a já se nechal strhnout a to mi už stačí .

• Tím, že víc lidí pracuje s IP adresami než s unsigned int-y, jasně připouštíš, že někdo má i jiné potřeby.
• Odpověď: Další debata na toto téma nemá smysl
• Jsou tu důvody, ale na některé neslyšíš, některé vlastnosti MySQL neprávem upíráš a další by zas jen rozvíjely diskuzi, a takovýto směr diskuze mi nesedí a klidně se jeho pokračování vzdám…

[crit.ik]

Co není součástí standardní instalace postgresu je prakticky zbytečné a nedá se s tím počítat pokud má aplikace využívající tento databázový stroj fungovat "všude".

[l0gik]

A kolikrát člověk píše aplikaci, která má fungovat všude a nemůže se spolehnout na to, že si bude moci nakonfigurovat server tak, jak mu to vyhovuje? IMHO je to v marginálním počtu případů.

[Filip Jirsák]

To neděláš dobře, Jaromíre, s těma sirkama…

[okbob]

validace by měly být umístěné v after triggeru, právě proto, že v before triggeru vlastně nikdy nevíš, jaká data se budou vlastně ukládat - i když to není záležitost MySQL, která může mít jenom jeden trigger.