Prosím přispěvatele výše, kteří si stěžují na to, že MySQL ničí data, aby uvedli nějakou konkrétní vlastní zkušenost.
Používám MySQL již od řady 3. V současné době mám již na několika serverech u našich partnerů nasazenou MySQL řady 5.0. Za mnoho let co MySQL používám se mi ještě nestalo, že by zničila data. Užívám MyISAM. Nepoužívám "lepší" schopnosti MySQL (například nepoužívám transakce, procedury, ...). Logika je na aplikační úrovni. Jde o webové aplikace na několika místech a všude do nich každý den zapisují desítky lidí. UPS na serverech vždy spolehlivě zajistily kompletní doběhnutí aplikace ("transakce", kterou aplikace provádí) i při výpadku proudu. Náhlý pád klienta nic pro webovou aplikaci neznamená.
Tedy ještě jednou, prosím o konkrétní zkušenost se zničením dat - já po mnoha letech žádnou nemám.
SELECT count(*), app_label, id, name FROM django_content_type GROUP BY app_label
Co budu mít v id a name? To co si MySQL nějak zvolí a ani nijak neupozorní. Třeba Firebird mě s tím zcela právem vyhodí a takový dotaz skončí chybou.
Nebo před koncem roku jsem dělal na importu dat ze starší php aplikace do nové djangové aplikace. Idea udělat si převod u sebe na lokále s posunutými id (ať je mezi ostrou db a importovanými daty mezera) a to pak poslat do ostré db končila na tom, že ALTER TABLE tbl AUTO_INCREMENT = 1000 u třiceti tabulek fungovalo v pohodě, ale u tří tabulek si MySQL vesele pokračovalo v id od původní hodnoty. Nakonec jsem to obešel tím, že jsem do postižené tabulky vložil záznam s id 999, naimportoval data a pak ten záznam zase smazal. Není nad to se drbat levou rukou za pravým uchem.
To že MyISAM nemá referenční integritu (a vlastně skoro nic) je známo, ale když tedy nad MyISAM tabulkou dělám cizí klíč, proč mě opět alespoň nedá varování, že to nepodporuje? Jinak i když mám veškerou logiku v aplikaci, tak alespoň tu referenční integritu by si slušná databáze měla umět ohlídat, protože když do db sáhnu přímo přes konzoli, tak si třeba i nechtěně mohu rozbít vazby.
Plus mě štvalo pár další chyb nebo nelogičností se kterými jsem se u MySQL setkal, teď si bohužel přesně nevzpomenu.
MySQL si to nijak nezvoli, ale vyplni poslednu/prvu (nie som si isty) hodnotu, ktoru najde vo fyzickej tabulke. Ak to budete zoradovat podla ORDER BY, tka vysledok bude iny. Zaujimave, ze po urcitej dobe ste na takyto logicky krok nedosiel. Kazda databaza si to riesi po svojom. Myslim ze podobne spravanie nie je definovane v SQL standarde.
Ten AUTO_INCREMENT je zaujimavy, nemozem potvrdit podobny problem, lebo si prave nevybavim ziaden vyuzitelny zamer posuvat umely primarny kluc.
MyISAM je dobre vyuzitelny pri statistich datach, kde sa nelapi na integritu, ale na rychlost spracovania. Cize do kritickych aplikacii vyuzitelne len na logovanie.
Pravda suhlasim s vami, ze niekedy by mohli mat lepsie hlasenie vystrah a chyb.
1) MySQL řady 3 byla neobyčejně spolehlivá. MySQL řady 5 už taková není.
2) MyISAM je relativně spolehlivé, byť ne zcela, ale InnoDb ničí data asi tak 20× lépe a radostněji.
3) Ad 2) bohužel MyISAM umí téměř kulové a 80% všech pokročilých featur je nad InnoDb.
4) Ad 2) Na 99% MySQL strojích je InnoDb předvoleno jako defaultní.
Jinak velmi doporučuji podívat se do changelogu MySQL, jaké i závažné chyby jsou opravovány i ve velmi vysokých číslech verzí MySQL. A pak shlédněte bugzillu, co tam zbylo a zděsíte se.
A pokud jste osobně se nikdy nesetkal s žádným problémem, pak Vám přeji, aby to bylo i nadále – ale je to více otázkou velkého štěstí, než aby to byla zásluha MySQL.
1) MySQL 3 bol neobycajny bordel. Neberte to osobne, ale prave ta verzia s kodovanim textu robila co sa jej zachcelo.
2) Spolahlive na data, ktore nevyzaduju integritu. Ti cislo ste si vycucal z prstu lavej alebo pravej ruky ?
3) InnoDB nie je jediny ulozny system. Nevyhovuje vam ? Mate X dalsich moznosti
4) Predvolene neznamena, ze jedine. Prikaz ENGINE ste este neobjavil ? A svete div sa, funguje to zmenit aj na existujucej databaze. Dokonca nad kazdou tabulkou.
Inak vrele odporucam zverejnit buglist Oracle. Jej, ze to nebude take lahke ? Ono to je closed-source ? A dokelu. To je smola. Ako potom mozete nadavat na jedno ked nie je dostupna aj druha strana mince ? Ci snad si myslite, ze Oracle, je snad bez chyb ? Odhadujem, ze to je tak narovnako.
Musím konstatovat, že žádný z diskutujících v tomto vlákně nepopsal svoji konkrétní vlastní zkušenost se zničením dat prostřednictvím MySQL. Ještě tedy jednou - prosím o konkrétní zkušenost se zničením dat!
Několikrát jsem řešil zničení dat MySQL u zákazníků, kde k tomu došlo chybou v MySQL. Nicméně popisovat konkrétně všechny okolnosti – to je na dost dlouhý článek, tak se nedivte, že se do toho nikdo nežene.
Doporučuji Vám web mysql.com a odskočit si jednak do changelogu (abyste viděl, jaké základní a kritické chyby se opravily i velmi vysokých verzích), a dále do bugzilly, abyste pochopil, jaké brutální chyby tam ještě zůstaly.
Dále zkuste web google.com.
Jinak se nezlobte, ale je zbytečné věnovat zbytečně čas něčemu, co už existuje. Navíc mě nikdo za tento čas neplatí, a proto je pro mě jednodušší Vám (už po několikáté) napsat, že je mi úplně egál, co si myslíte, a klidně si to tu vytapetujte Vašimi poznámkami třeba ještě pětsekrát. Děláte, jako by mě nějak záleželo na tom, abych Vás přesvědčil. Nezáleží, je to Vás problém, co si myslíte.
Ale ja som sa nepytal na opravu chyb, ktore mali pri spravnej konstalacii hviezd znicit data. Ja sa pytam na tie co ste spominal vy, alebo odkazy na nejake realne testy.
Cize mozete hovorit akokolvek intelignetne, a tvarit sa akokolvek urazene tak ste proste nedodal nic o co som Vas ziadal a len zahmlievate.
BTW: ja to tiez nemam zaplatene, ale nerozpravam tu o tom.