Jak sníst slona, resp. jak může

Jak sníst slona, resp. jak může MySQL bojovat s takovými giganty jako Oracle, IBM nebo Microsoft, se zamýšlí NewsFactor.

13.4.2005 19:19 | Michal Čihař | Zajímavý článek

Komentáře

[Michal Kubeček]

Proč je pořád taková mediální bublina jen kolem MySQL? Není to přeci jediná open source databáze. Technologicky k tomu mají PostgreSQL i Firebird daleko lepší předpoklady, nemusejí dohánět léta zaostávání.

[Michal Čihař]

Nejspíš protože za MySQL stojí firma, která produkt někam směřuje a tlačí to zákazníkům a médiím. IMHO za PostgreSQL ani Firebirdem nikdo takový není a bez marketingu to dneska nejde.

[Fiji]

A proč dohánět? A požírat slony? To nechápu. Kdyby se mi něco přihodilo, a chtěl programovat třeba nějaké jednoduché diskuzní fórum v PHP, tak mi stačí nějaká jednoduchá rychlá databáze, která umí SELECT a INSERT. Proč se má MySQL tlačit někam, kde je již hráčů dost, a vyklízet svoje pozice, kde si vede dobře? To mají vývojáři MySQL komplex, že ta jejich databáze neumí triggery nebo uložené procedury (a hlavně mi sem nepiště, že verze 5.x už je umí - když je budu chtít, použiju stejně jinou DB; a když je chtít nebudu, nepoužiju už ani MySQL, protože mi stačí něco jednoduššího, jako stará MySQL).

[Michal Čihař]

Protože v tom trhu je víc peněz, z toho že si uděláš jednoduchou aplikaci nad MySQL asi MySQL AB moc dlouho nevyžije .

[Zdeněk Štěpánek]

Zdravim

Tak tak, svata pravda, MySQL ma dobre pozice u jednodussich aplikaci, zejmena ve spojitosti s PHP a myslim ze si tam vede dost dobre. Pro me je to plnohodnotna databaze a zatim vzdy splnila moje pozadavky.

Zdenek

[David Jež]

Proc zaostavani? MySQL sice neni jedina open source databaze, nicmene zazite bludy o nejake pochybne ,,zaostalosti (ci ja nevim co)``, o tom ze mySQL ma byt snad jen jakasi ,,hracka``, ze se hodi jen na nejaka pritroubla PHP forka ci poobne kraviny nejsou nic jineho nez FUD. K cemu ma podle tebe slouzit databaze? Jak ma vypadat dobra databaze a jake ma mit pozadavky? Vzdy musis system posuzovat podle toho, jak je schopen za jakych kompromisu nebo bolesti vyhovet tvym pozadavkum. Ne podle vyctu casto polopochybnych features a dbat na kvantitu. Pokud je tvym pozadavkem aby databaze fungovala, byla to tenka a vykonna vrstva mezi daty a systemem nad ni tak te prece nezajima, jestli databaze umi nejake trigery, jestli ma nejake super mega hyper features, bez kterych nemohou trolove existovat. Naopak, sahnes po databazi ktera je jednoducha, dela jen to co potrebujes aby delala a dela to dobre, nesnazi se byt parni mlatickou a je dobre dokumentovana a podporovana. Take radeji sahnes po databazi, ktere snadno porozumis a budes ji lehce spravovat nez po nejakem obludnem moru, ktery je za trest uz jen instalovat a konfigurovat natoz spravovat. Jiste ze jsou oblasti ve kterych musis pouzit jinou databazi ktera podporuje funkce ktere potrebujes, ale kvuli tomu bych MySQL rozhodne neodsuzoval. Naopak, stejne jako ostatni bych byl velice nerad, kdyby se z rychle a elegantni MySQL stal nejaky druhy sileny Oracle... Doufam ze timto smerem se opravdu MySQL ubirat nebude
-djz

[Michal Kubeček]

Dobrý RDBMS pro mé použití bezpodmínečně musí mít kvalitní implementaci transakčního zpracování. Kvalitní implementaci si nepředstavuji tak, že transakce budou něco navíc, co bylo přidáno napůl proti vůli autorů, něco volitelného, u čehož mne databáze na každém kroku přesvědčuje, že bych to raději neměl používat.

Pokud je tvym pozadavkem aby databaze fungovala, byla to tenka a vykonna vrstva mezi daty a systemem nad ni tak te prece nezajima, jestli databaze umi nejake trigery

To mne právě zajímá docela dost. Bez triggerů se samozřejmě obejít dá (i když to není vždy ku prospěchu věci), ale vyžaduje to aspoň stored procedures - a MySQL ještě nedávno neměla ani ty. Tím nutila vývojáře, aby na stranu klienta přenesli mnohé z toho, co mělo být na straně databáze. Pro mne je takový model nepřijatelný, celkem běžně pracuji s aplikacemi, kde se data aktualizují z několika různých klientů, kteří jsou napsáni v různých jazycích a běží na různých platformách. Udržovat v takovém případě konzistenci dat na straně klienta (navíc bez efektivních transakcí) je nemyslitelné. A konzistence dat je v ostrém nasazení podstatně důležitější než rychlost.

Take radeji sahnes po databazi, ktere snadno porozumis a budes ji lehce spravovat nez po nejakem obludnem moru, ktery je za trest uz jen instalovat a konfigurovat natoz spravovat.

Věřte nebo ne, ale MySQL rozhodně není na správu jednodušší než Firebird. InterBase měla odjakživa pověst DBA-less databáze, hezky to vyjádřil nedávno Jim Starkey: "I originally designed the system so the only tuning parameters were page size and choice of indexes. And I'm no longer sure about page size…"

Naopak, stejne jako ostatni bych byl velice nerad, kdyby se z rychle a elegantni MySQL stal nejaky druhy sileny Oracle…

S tím víceméně souhlasím. Také si nemyslím, že MySQL může něco získat tím, že se pokusí být něčím na půl cesty mezi původním jednoduchým datastorem a plnohodnotným RDBMS. Protože zatím to vypadá, že půjde-li to takto dál, nebude pořádně fungovat ani jedno. Nemohu ale souhlasit s názorem, že MySQL je plnohodnotným RDBMS a že to, co jí chybí, je vlastně zbytečné, to v žádném případě. Při nasazení v prostředí, kde jsou data aktualizována více klienty současně, nemůže MySQL nahradit ani komerční produkty typu MS SQL nebo Sybase ani open source alternativy typu Firebird nebo PostgreSQL. O Oracle nebo DB/2 je škoda ztrácet řeč, to je úplně jiná kategorie (což neznamená, že pro ne-highendové aplikace nemůže být kterákoli z dříve zmíněných databází lepší než tito giganti).