mysql a kaskády
Zkouším nyní přemigrovat své MSSQL tabulky do MySQL, ovšem nedaří se mi vytvořit Foreign key.. nestále mi to předělává na INDEX
ALTER TABLE `sk_grgr` ADD CONSTRAINT `SK_GRGR_FK1` FOREIGN KEY (`child_grou_grgr`) REFERENCES `sk_grou` (`id_grou`) ON DELETE CASCADE ON UPDATE NO ACTION;
takže když smažu nějaký záznam z sk_grou, tak podzáznam v sk_grgr tam zůstane, což je špatně
skus vyhodit ON UPDATE NO ACTION
to nepomohlo, on nevytvoří ani ten cizí klíč
Este taka otazka, pouzivas InnoDB engine tabuliek? MySQL pouziva defaultne engine MyISAM, ktory cudzie kluce nepodporuje.
nyní jsem udělal export tabulk
jaký je rozdíl mezi všema engine?
to bude ta chyba :)
Takže já budu muset asi využívat jen InnoDB
tu najdes prehladnu tabulku, co ktory engine podporuje a co nie
http://dev.mysql.com/doc/refman/5.1/en/storage-eng ines.html
na fulltext search je urcite velmi pouzitelny. inak je ten engine uplne k nicomu.
Tak jako Oracle db mi to samozrejme pobavilo nejen ze o vykonu Mysql a O jeho kvalitach si myslim sve, ale druhak = vzdyt ten engine nic neporuje, to by umel kazdy "rychle nic neumet" pokud neumi constrainty (check, fk) tak se je pokusi duplikovat applikacni logika a to bude jeste pomalejsi :D
Nevidim do toho, ale na prvni pohled nechapu jak je mozne Engine definovat pro jednotlive tabulky jako ma tu v klauzuli, kdyz je jeden transakcni a druhy neni - a radeji snad ani nechci slyset co kdyz spustim transakci na tabulkach kde je pulka v tom a v pulka v onom.
porovnavat mysql s oracle je trochu nefer. Ano engines v mysql su trochu zhovadilost, ale ma to svoj vyznam.
Myslim, ze aj poradna bezi na mysql a tipol by som si, ze MyISAM tabulky sa vyuzivaju v pripade, ze niekto vyuzije policko Hladat vpravo hore.
Co sa tyka tvojej otazky k transakcii, tak odpoved je jednoducha. Pokial nieco v transakcii zlyha, tak transakcia zaucinkuje len na innodb tabulky.
Nechtel jsem to srovnavat, spise mi to pobavilo. Chapu ze to ma svuj vyznam, ale nechapu proc je to na urovni tabulek, v oracle bych nasel taky nejake nalaogie = compatibile parametr, editce = ale vzdy na urovni cele DB a ma to sve duvody.
Toho jsem se presne bal tedy:
update ucet_inddo=ucet_indoo-10;
update ucet_tam_mysisam=ucet_tam_myissam+10;
insert into log_indoo values (prevedeno);
(a zde se mi to vymrdne)
commit;
Taky ucet_tam_mysisam ma na konte vic penez a ani stopa po tom, ze by neco bylo spatne...
Tvoj priklad ma spravnu dedukciu, ale takto by to asi nikto (znaly problematiky) neriesil. Pokial nieco nutne potrebujes dat do transakcie, tak automaticky InnoDB pripadne iny engine, ktory transakcie podporuje.
MyISAM bud na male databazy, alebo ako doplnok, ked chces vyuzit fulltext.
Nekdo znaly by to dal do InnoDB, ja tomu rozumim, jen si myslim ze kdyz nekdo alteruje tabulku ci re-creatuje, udela nějaky CTAS (create table as select, doufam ze mysql umi), prevede schema atd. Omylem dropne tabulku a pak ji vytvori z nejake zalohy atd. Tak tam bude "černá ovce" pod nějakým defalitním enginem, která se neprojeví měsíce, a roky a muže mít neskutečný následek - nebo opačně roky to tam bude pomrdávat.
Spis mi desi ze to lze mixovat nez to ze je tech enginu vic. V oracle si jde taky casto vynutit "uchylne chovani" viz asynchorni commit ale je to presne definovane a nespusti to nikdo, kdo to nema nastudovane, omylem to nastavit nelze,
Keď sme už pri tom, tak považovať prázdny reťazec za NULL je "úchylné chovanie" v Oracle by default.
by default je to trosku jeste uchylnejsi ;) ne vzdy je povazovat prazdny retezec za NULL, v 99% pripadu ano, pri indexovani asociativniho pole nikoliv (ale nesmi se to protahnout pres promennou, ktera by tomu dala realnej NULL)
takže asi všude používat default, ale tam kde chci cizí klíče, tak použiji innoDB
ja mysql rozumim jako koza petrzeli, nicemne podle manualu to ma byt ENGINE=INNODB, mas?
Jinak je problem s fk nebo s timto typem checku, tzn zafunguje kdyz tam vlozis child bez parenta?