Starší komentáře ke článku: Myslíme v MySQL 4
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 8.12.2003 10:47:56
<I>"Přestože všichni neustále opakují, jak důležité je tuto problematiku znát a chápat, většina programátorů ji dosud statečně ignoruje. To se týká především autorů web-based aplikací, jejichž hříchy jsou v této oblasti notoricky známé."</I>
Proč na toto téma nenapsat článek? :-) Pokud vím, článků o MySQL je tu sice na Intervalu hodně, ale převážně "referenčních", a žádný se nezabývá právě tím, jak v určitých situacích udělat jak stavěnou tabulku apod., a v čem se nejvíce chybuje při návrhu...
Datum vložení: 8.12.2003 10:53:06
Můžete začít, já hrubě nestíhám ;-)
Datum vložení: 8.12.2003 13:46:42
Taky si myslim,ze by se to hodilo. A ne jen clanek,ale klidne i nejaky miniserialek ....
Nejaky kousek teorie a pak treba par prikladu, jak autor pri svem navrhu postupoval ...
Vse o teto problematice se hodi :)
Datum vložení: 8.12.2003 16:16:39
Odbornou literaturu si kupuji vyjimecne, a vzdy dlouze vybiram, protoze maloktera kniha pro me neni ztratou casu. (.... jsem skromny, ze?)
Ale zrovna tahle knizka o MySQL mi hned padla do oka. Zadne popisovani banalit, ktere kazdy pochopi sam od sebe, zadna referencni prirucka, ale vypoved "machra", ktery s MySQL uz neco zazil.
Autor napriklad resi konkretni ulohu v MySQL, navrhne nekolik reseni, zmeri casy, vyhodnoti ktere je uplne mimo, ktere nejefektivnejsi - proste takhle si predstavuju vybornou knizku.
Stoji 690 Kc - verte, ze jde o 7 stovek, kterych nebudete litovat. Samozrejme je muzete usetrit, a cekat na clanky "zdarma", treba na Intervalu. Jenze, Interval tezko muze suplovat 700 stran kvalitni knihy, vzdelani proste neco stoji....
Datum vložení: 8.12.2003 23:40:32
<I>Nová verze MySQL 4 vbrzku většinu těchto hlasů umlčí, neboť zachovává všechny dobré vlastnosti předchozích verzí a rozšiřuje je o všechny vlastnosti, které dosud chyběly</I>
<P>
Všechny? Tak proč na <a href='http://www.mysql.com' target='_blank'>http://www.mysql.com</a> tvrdí, že stored procedures (a triggery) jsou plánovány ve verzi 5.0 a views ve verzi 5.1?
Datum vložení: 8.12.2003 23:45:23
Ale ale, vidím, že debata na jednom místě Vám nestačí ;-)
Nu, mohu pouze zopakovat aktuální informaci z vývojářské a betatesterské konference, která stored procedury plánuje do verze MySQL 4.2, ale kdo ví, jak to nakonec bude ;-)
Datum vložení: 9.12.2003 0:12:25
Hlavně jde o to, že se mi nelíbí, pokud je (nejen zde) široce prezentován názor, že MySQL má vlastně všechno, co je k plnohodnotnému vývoji aplikací potřeba a že zbývá jen doplnit pár drobností - stejně jako se doplnily transakce, když tedy uživatelé jinak nedali. Protože o programování něco vím, je mi jasné, že ty "drobnosti" naprosto podstatně mění samotný princip fungování databáze. Takže buď to bude znamenat poměrně hluboké zásahy (a hodně času) nebo se to udělá naoko, "aby to nějak bylo". A podle toho, co jsem zatím viděl, se MySQL vydává spíše tou druhou cestou.
Proto cítím potřebu varovat začátečníky neznalé problematiky před představou, že MySQL je takovým prototypem SQL serveru, který je vhodný jako začátek, protože se na něm naučí všechno podstatné. Realita je přesně opačná, je to asi tak, jako by se naučili Forth v naději, že z něj později snadno přejdou na C++ nebo Javu.
Datum vložení: 9.12.2003 0:32:32
A to, co tu prezentujete Vy, zase já považuji za opačný extrém - tvrzení, že s MySQL mohou pracovat jen nedoukové a kdo se jednou této DB dotkne, provždy zůstane nečistý.
MySQL vznikla doslova z ničeho jako backend pro jednoduché webové prezentace a web-based aplikace v době, kdy všechny ostatní DB systémy nad webem ohrnovaly nos. Implementovala pečlivě vybranou a optimalizovanou množinu funkčnosti, potřebnou pro realizaci svých cílů, a konkurenci jednoduše smetla. Dodnes na většinu potřeb webových aplikací bez problémů stačí.
Je velkým plus pro tvůrce MySQL, že nezaostávají za potřebami svých uživatelů a snaží se průběžně doplňovat funkčnost systému podle jejich rozrůstajících se požadavků. Díky tomu už se MySQL dostala například v obchodních transakcích (SAP, ebXML) tam, kde dříve vládla totalita Oracle a kam ostatní oslavované systémy dosud ani nenakoukly.
Rád bych tedy věděl, z čeho soudíte, že MySQL místo řádného vývoje pouze maskuje a obchází své nedostatky?
Datum vložení: 9.12.2003 0:58:27
1. Takové tvrzení jsem neprezentoval, pouze jsem prezentoval názor, že přechod z MySQL na jinou databázi je řádově složitější než adaptace z jiné alternativy. Jednoduše proto, že MySQL se snaží maximum práce přenést na klienta, zatímco ostatní se snaží, aby s daty pokud možno manipuloval server, protože k nim má blíž a není je třeba pořád přenášet tam a zpátky (o řešení konfliktů nemluvě).
2. Nejsem přesvědčen, že by SQL server musel nutně nějak podporovat web, aby šel pro web-based aplikace použít. Prezentace je úkolem pro klientskou stranu, případně middleware.
3. Některé změny ale dost dobře nejdou řešit evolucí, místo toho je nutná revoluce. Třeba právě implementace transakcí je věc, která se IMHO nedá řešit jen jako rozšíření. Mají-li dobře a efektivně fungovat, musí být transakční zpracování zakomponováno v samé podstatě systému.
4. Ta formulace je opět přehnaná. To, co jsem měl na mysli, souvisí s předchozím odstavcem. Vidím-li, že v MySQL je možné, aby se transakční zpracování týkalo jen některých tabulek v databázi, jen těžko mohu uvěřit tomu, že transakce nejsou implementovány jen jako "něco navíc".
Datum vložení: 9.12.2003 1:10:23
1. Nechápu, proč by měl být přechod na jinou databázi z MySQL složitější. Potřebné techniky není problém se doučit. (Nehledě na to, že Váš argument o manipulaci s daty je pouze jedním z názorových proudů.)
2. Pokud SQL databáze neposkytuje potřebné rozhraní, je celá klientská strana aplikace na suchu. Databáze bez podpory pro skriptovací jazyky je v tomto případě databází bez podpory web-based aplikací.
3. Ano, některé změny se musí řešit revolucí. Proto má také MySQL 4 naprosto odlišné jádro, které nebylo z předchozí verze převzato, ale naprogramováno "na zelené louce".
4. Co je špatného na tom, když RDBS zvládá více různých druhů tabulek, z nichž některé pro transakce nejsou přizpůsobeny? IMHO je vždy lepší, když si člověk může vybrat - potřebuji-li transakce, použiji transakce, nepotřebuji-li transakce, proč bych nevyužil výhod jiného typu tabulek?
Datum vložení: 9.12.2003 1:41:49
1. Mou první (SQL) databází naštěstí nebyla MySQL ale Interbase. Když jsem později použil pro některé projekty Sybase nebo MS SQL, neměl jsem s tím v podstatě žádné větší problémy. Když jsem ale musel použít MySQL, bylo to pro mne utrpení. Je jasné, že přechod opačným směrem bude jednodušší, vždyť přece uživatel nemusí ty vymoženosti navíc používat, ale... to je právě ten problém. Doučit se je samozřejmě může, ale tady jde o odlišný přístup a určité návyky se odstraňují velmi těžko.
Rozdíl mezi tím, zda data zpracovávám na serveru nebo je neustále přehazuji mezi klientem a serverem, se naplno projeví v okamžiku, kdy klient a server neběží na stejném počítači. Viděl jsem aplikace, kde oddělení databázového serveru od webového přineslo urychlení, viděl jsem i takové, kde to aplikaci zpomalilo do nepoužitelna - na některé věci není ani 100Mb/s Ethernet dost rychlý.
2. API, které poskytuje databáze, je jen jedna strana problému. To API mají všechny a většina ho má zpracované lépe než MySQL. V každém případě ale API databáze není nijak závislé na tom, jestli je určeno pro skriptovací jazyk nebo třeba aplikaci psanou v C. Druhou stranou je podpora ze strany skriptovacího jazyka, která to API využívá. Takže bychom se místo toho, že MySQL začala podporovat skriptovací jazyky dříve než jiné databáze, měli spíš bavit o tom, že skriptovací jazyky (zejména PHP) adoptovaly MySQL dříve než jiné databáze a ptát se po důvodech.
4. V zásadě by nebylo špatné, pokud by bylo možné přistupovat transakčním nebo netransakčním způsobem k celé databázi. To ovšem jde i jinde, stačí provést po každé akci commit. Ale kombinovat tyto dva přístupy pro jednotlivé tabulky v rámci jedné databáze považuji za hodně špatný nápad. Ostatní systémy jdou přesně opačným směrem: umožňují naopak implementovat transakce nad více databázemi (dvoufázový commit).
Datum vložení: 9.12.2003 8:22:48
pro zacatecniky ma ale my sql, dve vyhody, je zadarmo a spolupracuje s apachem ( ktery je taky zadarmo ) a oboje jde jeste celkem snadno nainstalovat a nemusite nic krast, za druhe my sql + apache + php mam jak na windoze tak na linuchovi a navic vetsina freehostingu poskytuje my sql
Datum vložení: 9.12.2003 11:24:53
Takže si proberme vaše argumenty postupně:
- PostgreSQL i Firebird jsou zadarmo, mají dokonce volnější licenční podmínky než MySQL
- PostgreSQL i Firebird spolupracují s PHP (předpokládám, že myslíte PHP, ne Apache), v mnoha ohledech dokonce lépe než MySQL
- instalace je také jednoduchá, výjimkou je pouze PostgreSQL na Windows, naopak instalace Firebirda na Windows je jednodušší než u MySQL
- množství podporovaných platforem určitě není argumentem proti Firebirdu a nebudeme-li lpět na win32, pak ani proti PostgreSQL
Takže jediný skutečně relevantní argument z vašeho příspěvku je ten úplně poslední (veřejné hostingy). To samozřejmě nelze podceňovat, ale je to klasický začarovaný kruh. Bude-li poptávka, bude i nabídka (jako že je už teď, stačí hledat).
Datum vložení: 9.12.2003 15:19:08
Myslime tady Firebird tenhle - <a href='http://firebird.sourceforge.net/' target='_blank'>http://firebird.sourceforge.net/</a> nebo tenhle <a href='http://www.ibphoenix.com/' target='_blank'>http://www.ibphoenix.com/</a>, je mezi nimi nejaky vztah, krome zrcadlove provedeneho loga apod. ...
Datum vložení: 10.12.2003 2:53:37
Vztah je takový, že jde o dvě stránky vztahující se k témuž projektu. Na SourceForge je hlavní zdroj, kde najdete aktuální verze (release i vývojové), dokumentaci atd. IBPhoenix je spíš takový magazín s informacemi o novinkách, zajímavých článcích, souvisejících produktech atd. (Jsou tam ale i sekce download a dokumentace.) A konečně bych z webových zdrojů doplnil ještě <a href='http://www.ibphoenix.cz' target='_blank'>http://www.ibphoenix.cz</a> (česká verze <a href='http://www.ibphoenix.com)' target='_blank'>http://www.ibphoenix.com)</a> a <a href='http://www.firebirdsql.org' target='_blank'>http://www.firebirdsql.org</a>.
Datum vložení: 16.12.2003 16:29:15
Nemůže nereagovat. MySQL má své výhody především v jednoduchosti. Mockrát bych jí použil, ale neudělal jsem to, protože licence mi ukládá za MySQL tvrdě platit. A to ne malé částky.
Tím pádem se pro mě stala MySQL spíše webovou databází, ale pro jiné použití ji vylučuji z důvodu toho, že má daleko k tomu, a by byla zadarmo.
MySQL je malá šikovná db na jednoduché modely. Na nic víc se moc nehodí, a pro spoustu projektů, kde by MySQL šlo ideálně využít je vyloučena právě cenou.
Datum vložení: 16.12.2003 21:51:24
Muj kamos umi telefonovat :-))))
Datum vložení: 21.10.2004 13:30:05
souhlasím, tahle "triáda" je opravdu hodně rozšířená. Netvrdím, že na MySQL lze založit jakýkoli SW, ale na spoustu věcí to je vyhovující. Stačí se podívat na to, kolik webových aplikací je na téhle trojce založeno
Datum vložení: 9.12.2003 9:53:09
Helena k to presne vystihla. Debata mezi pany Malkem a Kubeckem nahore je spise o velkych projektech, ktere ovsem vetsinou delaji zkuseni odbornici, pro ktere je takovato debata nezajimava. Vetsina webovych aplikaci ma par desitek stranek a DB potrebuje na nejake forum, mailing list, seznam clenu a podobne. Pro takove pouziti je MySQL nejen dostacujici, ale take velice vhodna prave z duvodu uvedenych Helenou.
A kdyz uz jsme u tech knizek, tak pred casem vysla kniha MySQL profesionalne, ktera pokryva zhruba stejnou oblast jako kniha propagovana v clanku, s tim rozdilem, ze bere v uvahu verzi 3 i verzi 4. Hosting servery, ktere vetsina bezny webu pouziva, budou hodne opatrni s prechodem na verzi 4 a jeste jim to nejakou dobu potrva. Pri vice mene stejnem obsahu a stejne cene mne prijde MySQL profesionalne v soucasnosti jako uzitecnejsi.
Datum vložení: 9.12.2003 15:06:22
Jestli si to dobře pamatuji, původně byla MySQL navržena jako datový sklad pro OLAP -- tj. byla optimalizována na rychlost čtení a postrádala transakce a další z tohoto pohledu zbytečné věci. Na webu se začala používat až později.
Datum vložení: 9.12.2003 15:37:31
Nechci nijak MySQl snzizovat, ale souhlasim s Michalem Kubeckem. Bez ulozenych procedur a triggru je to jako back end pro trochu vazneji minene webove aplikace nepouzitelne. Porovnam li to napriklad s tim, co mi nabizii Oracle ci MSSQL tak neni o cem mluvit. Osobne neznam projekt v oblasti B2C ci B2B, kde byla MySQL pouzita jako back end.
Datum vložení: 9.12.2003 16:25:15
Já myslím, že je to pořád o tomtéž...
Potřebuju v DB u vytváření běžného RS nebo Knihy návštěv triggery? Nepotřebuju. Stejně tak nepotřebuju OOP resp. třídy v PHP...
Ostatně, docela hezky je na podobné věci odpovídáno na:
<a href='http://www.dbsvet.cz/ptejte/' target='_blank'>http://www.dbsvet.cz/ptejte/</a>
Datum vložení: 10.12.2003 9:05:07
<I> Potřebuju v DB u vytváření běžného RS nebo Knihy návštěv triggery?</I>
A potrebujete v aute klimatizaci, automatickou prevodovku, elektronicky ovladani oken, stresni okno? Takhle prece nejde ta otazka polozit! Napriklad trigger, ktery by se staral o mazani child zaznamu v pripade, ze smazete jiejich parenta ma opodstatneni vsude. Samozrejme muzete to udelat programove stejne jako stahnout si okenkou rukou.
Tema OOP je pro tenhle clanek v OT rovine.
Datum vložení: 10.12.2003 12:16:26
Souhlasím. Já jen že se na tohle hodně často zapomíná (záměrně?). I v jedné asi 20 let staré knížečce pro programátory je kapitola nesoucí název onoho velice známého rčení: "Nechoďte s kanónem na vrabce".
Datum vložení: 10.12.2003 15:57:10
Jen jestli nejde ani tak o rozdil v klimatizaci, jako spis jestli potrebuju odvezt jenom sebe, nebo jeste taky 10 tun sterku. V prvnim pripade vystacim, kdyz na to prijde, i s mopedem, na ten druhy budu potrebovat poradny nakladak. Oracle si prece na knihu navstev porizovat nebudu.
Datum vložení: 19.5.2004 16:58:00
No, jestli tohle nekdo dela pres trigger, tak by mu meli zakazat jenom priblizeni ke konzoli databaze.
Datum vložení: 19.5.2004 16:58:56
Pardon, to jsem reagoval na:
<I>Napriklad trigger, ktery by se staral o mazani child zaznamu v pripade, ze smazete jiejich parenta ma opodstatneni vsude. </I>