Názory k článku
Používat či nepoužívat MySQL?
-
Palo (neregistrovaný)Neviem ci CMS je to iste ako databaza ale JDBC a ODBC uz davno vyriesili problem vyberu databazy. Nebodaj nieco ako Hibernate dovoluje na databazu uplne zabudnut. Nech si to vyriesi integrator/instalator. Ako programator na to nemam cas a zbytocne nebudem svoj produkt na nieco viazat ked nemusim (ziadne vyhody to neprinasa).
Ako integrator iba niekolko postrehov:
- MySQL ma niektore funkcie este nevyzrete (ak porovnavame z Oracle alebo PostgreSQL)
- PostgreSQL nema zasadne problemy. Fajn. Nieco medzi MySQL, pobliz DB2 a pod Oraclom.
- Oracle je uplne nadupany a naslapany stroj ale stoji bubaky (XE verzia je mimochodom zadarmo do 4GB dat a 1GB RAM). Kto tvrdi opak nedovidi si koncek nosa. Ma to muchy ale ani by som sa neodvazil porovnavat to s MySQL.
- DB2 je tiez dobre pouzitelna len treba pri navrhu viac rozmyslat. Potom sa to cloveku vrati vo vykone. Aj ked to SQL je obcas krkolomne (napr. rekurzivne selecty)
- Este by som spomenul HSQLDB ktore je tiez docela solidne na to ze vie bezat ako embedded system. Mimochodom bude (uz je?) integrovana ako nativna baza pre OpenOffice.
-----
Autor prispevku neruci za to ze jeho nazory sa budu zhodovat s Vasimi. -
Radek Hulán (neregistrovaný)MySQL je primitivní filesystém, ne DB. Zkuste si třeba zjistit, jaká práva potřebuje "CREATE TRIGGER".. Podobně mizernou funkčnost neměl Oracle ani v roce 1990, a v roce 2007 je zcela jinde.
MySQL je výborný případ open-source odpadku, který se používá jen na miniaturní projekty, na cokoliv jiného je potřeba closed-source komerční kvalita. -
T (neregistrovaný)http://www.systemonline.cz/site/data-warehousing/insight.htm
No já si taky adresně přisadím, pro změnu na RH: některý filesystémy jsou Case-Sensitive! -
Zero (neregistrovaný)MySQL je primitivní filesystém, ne DB.
Ehm to je asi preto ze sa na to pozerate cez oci primitiva...
Zkuste si třeba zjistit, jaká práva potřebuje "CREATE TRIGGER"
A kde vyuzivate ten CREATE TRIGGER???
MySQL je výborný případ open-source odpadku, který se používá jen na miniaturní projekty, na cokoliv jiného je potřeba closed-source komerční kvalita.
Ale toto fakt??? Tak preco sa vyuziva na Free webhostingoch??? -
Radek Hulán (neregistrovaný)"A kde vyuzivate ten CREATE TRIGGER???"
Každý, kdo zná trošku více než základy SQL. Pubescenti znají jen INSERT/SELECT/DELTE a myslí si, že toto je databáze. Velký omyl. Uložené procedory, triggery, a celá aplikační logika v DB volaná z libovolného klienta je skutečná databáze, a k tomuto se MySQL ani zdaleka nepřibližuje.
Nejvíce dementů řve tehdy, když nemají znalosti. Zkus si něco nastudovat po PL/SQL.. Osobně pracuji s Oracle od roku 1992, a výsměch zvaný MySQL se za nic lepšího než "filesystém" nedá považovat. -
Pravděpodobně proto, že od MySQL nechtějí vůbec nic jiného než uložit balík naměřených dat. A to pokud možno rychleji než se jim zahltí paměťové cache. A na to je MyISAM ideální. Pokud ovšem nepracujete s vědeckými daty (většinou se jedná o časové řady, kde můžete tak maximálně sledovat korelaci), potřebujete jištěnou doménovou a referenční integritu. Například abyste si nesmazal číselník zboží, které máte ještě na skladě. Pokud implementujete doménovou a referenční integritu v aplikaci, tak máte jistotu, že uživatel nic nezvoře, nicméně, kdo vám totéž zaručí za aplikaci? Vzhledem k tomu, že obé integrity jsou podporované v SQL, tak jejich definování i vynucení je elementární, bezpracné a účinné pro uživatele. Interně to není nic jednoduchého, a pro MyISAM tabulky s hrubým zamykáním to nelze provést nijak efektivně (diskuze v dbsvete http://www.dbsvet.cz/comment.php?akce=view&cisloclanku=2007050201 ).
MySQL se držela Microsoftí rétoriky, co neumíme je k ničemu a nikdo to nepotřebuje. Naštěstí teď obrátili, vzhledem k tomu, že už jakž takž výšší db operace zvládnou. Jak InnoDB, tak nový Falcon referenční integritu podporuje. -
Tom (neregistrovaný)Na uvod, robim s Oraclom aj MySQL. Nie od vcera. Naozaj dlho. V zavislosti od projektu a ulohy.
Avsak, drobnu poznamku si neodpustim.
Pravdepodobne si naozaj velky k***t, lebo iba k***t napcha aplikacnu logiku do DB. Toto sa riesi tretou vrstvou, aplikacnym servrom. Databaza ma za ulohu udrzat integritu dat (do urcitej miery). Nic viac nic menej.
Vsetko ostatne je na aplikacnom servri. Klienti dnes samozrejme co mozno najtensi.
Pochopis, ked zacnej pracovat na projektoch kde objem dat dosahuje radovo stovky az tisice GB. Udrzat takto velky cluster v behu, zabezpecit skalovatelnost a zamedzit single point of failure nie je naozaj jednoduche. Najma bez app servru.
Takze zdar primitivnym k*****m! :) -
McBig (neregistrovaný)Delam to velice nerad, ale zde se musim zastat naseho mileho genia, byt je vedle jak ta jedle a ja osobne bych mu nesveril ani instalaci icq.
Pro genia (RH): Myslq dnes opravdu umi ukladat aplikacni logiku primo do DB, laskave si zkuste obcas aktualizovat verzi, nebo alespon znalosti, oni to rozumni admini jednou za cas opravdu delaji.
Nicmene, nadavat nekomu do k****tů, protoze chce od db nejaky ten trigger nebo funkci je jednak nesportovni a neslusne a hlavne kratkozrake. Ono totiz cas od casu pride situace, kdyz je potreba do db neco takoveho ulozit, aby si clovek ulehcil praci s aplikacni vrstvou. Ze ste se s tim nikdy nesetkal za vas profika nedela ! A u "malych" aplikaci ktere jsou nad MySQL stavene vytvaret neco jako aplikacni server a k nemu klienta - to je velmi neefektivni. A to nemluvim o tom, ze do jedne DB pristupuje nekolik ruznych systemu, ktere s nim pracuji primo (treba autentikacni mechanismy ruznych serverovych sluzeb).
Proto prosim, nenechavejte se zbytecne vyprokovat ceskym vtipem jmenem Radek Hulan, jen se proste usmejte nad jeho nazory, dyt je to fakt zabava :) -
a) Zbytecne urazis lidi.
b) Mozna pro projekty o kterych mluvis je pouziti aplikacnich serveru nezbytne. Nicmene takovych je minimum. Ulozene procedury, tj. aplikacni logika v db ma minimalni rezii, uzke hrdlo je v SQL prikazech, takze neni zadny zvlastni duvod proc se branit ulozenym proceduram (za predpokladu, ze jim rozumis). Misto osocovani ukaz argumenty.
Spolupracoval jsem na projektu Garuda, kdy je 98% aplikacni logiky v databazi, aplikacni vrstva je fakticky jen prostrednik mezi databazi a AJAX klientem. Zatim se tenhle "sileny" navrh osvecuje. Samozrejme, ze architektura Garudy ma svoje specifika a neni vhodna pro urcite typy projektu, pro beznou vnitropodnikovou agendu naprosto postacuje.
Rozdil mezi aplikacnimi servery a ulozenymi procedurami se tak jako tak stira a bude stirat. Jazyky typu PL/SQL, PL/pgSQL nebo SQL/PSM maji minimalni rezii a umoznuji efektivni zapis kodu. Tam kde nestaci (vykonove nebo obsahove) neni problem pouzit .NET, Javu a dalsi. Naopak si dovolim tvrdit, ze pro celou radu projektu jsou aplikacni servery nevhodne nebo minimalne nekvalifikovane a chybne pouzite. Coz ve vysledku vede k silenym hw. pozadavkum. -
Tom (neregistrovaný)Na uvod, robim s Oraclom aj MySQL. Nie od vcera. Naozaj dlho. V zavislosti od projektu a ulohy.
Avsak, drobnu poznamku si neodpustim.
Pravdepodobne si naozaj velky k***t, lebo iba k***t napcha aplikacnu logiku do DB. Toto sa riesi tretou vrstvou, aplikacnym servrom. Databaza ma za ulohu udrzat integritu dat (do urcitej miery). Nic viac nic menej.
Vsetko ostatne je na aplikacnom servri. Klienti dnes samozrejme co mozno najtensi.
Pochopis, ked zacnej pracovat na projektoch kde objem dat dosahuje radovo stovky az tisice GB. Udrzat takto velky cluster v behu, zabezpecit skalovatelnost a zamedzit single point of failure nie je naozaj jednoduche. Najma bez app servru.
Takze zdar primitivnym k*****m! :) -
uzivatel (neregistrovaný)Tak toto napis IBM, ktora v 70tych rokoch definoval pojem DATABAZA a vysmeje ta. Vtedy to bol prave skutocne INSERT/SELECT/UPDATE/DELETE. Vsetko co sa da spravit cez Triggery sa da v aplikacnej logike spravit taktiez.
Takze ten pubescentn ako nazyvas si akurat len ty a este k tomu hlupak, ktory vie len do kazdeho nadavat aky je nevzdelany. Mozno ze mas inteligenciu, ale to co robi cloveka normalnym je ROZUM a ten ty zjavne nemas.
Proceduralny jazyk ma MySQL taktiez. Zobud sa, nehovorime o MySQL 3. Doba pokrocila. Ak pracujes s Oracle tak by si mal asi vediet, ze to nebola databaza primarne urcena na webove projekty, kde MySQL na toto presne stavane bolo, tak isto ako PHP. Obaja boli vo svojich zaciatkoch priekopnicky, potom zaspali a teraz to dohanaju.
Ak sa ti nepaci tak to nepouzivaj. Ale ty stale budes nadavat vsak ? Vidiet, ze idiot sa nezaprie. -
Zero (neregistrovaný)Pre Vasu informaciu 15 mi bolo uz davno a o SQL viem dost na to aby som Vam mohol oponovat.
Aplikacna logika v DB??? Hmm ja som si myslel ze to sa riesi cez aplikacny server nie v DB. Su sice situacie kedy to treba, ale je ich malo. Ktoru verziu MySQL mate na mysli??? od verzie 1.x sa toho vela zmenilo. Verzie 1.x fakt bola iba FS, ale skuste si nainstalovat novu 4.x, resp. 5.x... -
anonymnízalezi vykon ceho :)
na rychle ne az tak komplikovane casto opakovane dotazy, kde neni potreba nejak pokrocile kontrolovat integritu to je idealni
ale podnikovou aplikaci nebo dokonce DWH bych na to fakt nepostavil
je to proste trochu jina trida, ktera se hodi na neco jineho
a mimochodem ten lepsi vykon mysql podavalo s InnoDB nebo MyISAM? :) -
A PostgreSQL, tez OSS se Vam take nelibi? Ja s ni jsem naprosto spokojen a abych rekl pravdu ani MySQL mi nikterak nevadi, je to dobra databaze, byt ma sve vady. SQLite je take OSS, na nektere mensi vecicky perfektni nastroj. A co Firebird? Vsechno je to OSS ... nerikam, ze MS-SQL je spatna, neznam ji, nemohu soudit, ale rozhodne bych OSS databaze neodsuzoval, ba prave naopak. Tedy alespon pokud mate zajem bavit se ve vecne rovine a ne bulet jak male decko, ze se Vam nelibi pepickova babovicka, protoze ji ma hezci. -
hlavac (neregistrovaný)Před pár lety když jsem se o to zajímal mi na PostgreSQL vadil především jeho "optimistický" izolační model, to že klient v rámci transakce neviděl změny které provedl, a pak provázanost se systémovým locale. Nevim možná je to už jinak?
Jinak rychlost není v databázích všechno.
Velmi šikovné jsou transakce a s tím spojené vychytávky:
- konzistence a odolnost při havárii (při havárii se rozdělané transakce zahodí, dokončené zůstanou, data zůstanou konzistentní)
- záruka že se data neztratí poté co klientovi bylo potvrzeno jejich uložení (např. vinou pádu když jsou data ještě v diskové cache)
- izolace ve víceuživatelském provozu - podle mne nejvíce nedoceněná vlastnost - že se např. v serializable izolačním módu nemusíte vůbec starat kdo co s databází zrovna dělá a jestli vám to nakopne vaše data - databáze dělá zamykání sama a nejhorší co můžete spáchat je deadlock a opakování transakce... tohle ale neumí pořádně (= výkonně) ani většina komerčních databází a vymýšlí si všelijaké omluvy proč to vlastně ani nechceš ;)
Moc to usnadněuje složité aplikace s více uživateli kde není předem známo kdo se v tom bude jak vrtat (např. manažer přímo přes SQL klienta)
Mysql je rychlá pokud vím jen s myisam enginem a ten stojí za houby ze všech ostatních hledisek (na která je dobrý innodb ale zase není rychlý, no).
Nemám rád mysql protože je populární jen kvůli stádové mentalitě lidí co databázím nerozumí vůbec :) -
McBig (neregistrovaný)Kdyz si date tu praci (omlouvam se ale hledat to ted vazne nebudu) najdou se na netu ruzny benchmarky, podle kterych opravdu innodb je rychlejsi nez myisam, mam pocit ze jde predevsim o indexy. Takze opet tu je prostor pro ladeni zda index ano ci ne a jaky prip. kolik. Stejne jako je tento prostor u Oraclu, kdy se proste vyplati nektere indexy nepouzivat :)
-
Innodb automaticky clusteruje a pouziva urcite neciste techniky, a tak muze byt opravdu rychlejsi nez MyISAM. MyISAM ma mnohem jednodussi strukturu a podstatne mensi rezii pro operace UPDATE, DELETE, INSERT, takze pokud se v benchmarku pouzivaji tyto operace, tak na tom bude MyISAM lepe. Na druhou stranu, MyISAM zamyka na urovni tabulek, oproti InnoDB, ktere nezamyka nebo dovoluje zamky na urovni radku. Takze v benchmarkach, ktere sleduji chovani databaze pri viceuzivatelskem pristupu (zalezi jakem), tak u MyISAM vykon strme klesa s rostoucim poctem uzivatelu (vlivem zamykani).
-
Koukám PostgreSQL je i ve verzi 8.2 pořád stejný shit jako kdysi.
Jejich "serializable" izolační level vůbec nesplňuje kritéria serializovatelnosti.
Problém je v tom, že používají snapshot dat tak jak byla na začátku transakce pro všechna čtení v rámci transakce. To může fungovat jen u read only transakcí, při update to způsobí rozpad konzistence ve víceuživatelském režimu. Ten jejich podělaný "optimistický" model :) Ach jo. -
Full serializable by znamenal zamek v kazdem radku, ktery prectete, coz ve vetsine pripadu neni potreba. Pokud by mohlo dojit k problemum s konzistenci, pak je treba pouzit SELECT FOR UPDATE, ktery pozamyka prectene radky, cimz se blizite skutecne serializaci.
Dobra prezentace na toto tema (vcetne vysvetleni proc a jak neni serialisable transakce plne serialisable) najdete http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/concurrency.pdf
Chce si to precist dokumentaci -
> Full serializable by znamenal zamek v kazdem radku, ktery prectete
Ne nutně. Nezaměňujte jedno možné řešení problému s jeho definicí. Aby byly transakce serializovatelné stačí aby se zdálo že proběhly v nějakém pořadí jedna po druhé, tedy aby nepoznaly vliv ostatních transakcí. O zámcích tam nic není ;) Nehledě na to že potřebujete zámky na predikáty, ne na jednotlivé řádky (protože v případě instertu třeba ještě neexistují).
Stačí například zavést read only transakce (s multiversion) a update transakce vykonávat sériově a máte taky plně serializable izolaci s vysokým výkonem pro aplikace s převahou čtení (např. web). Žádné zámky, žádný overhead.
> Chce si to precist dokumentaci
Optimistický multiversion model izolace PostgreSQL jsem studoval _velmi pečlivě_. Právě proto remcám ;)
Hlavní nedostatek vidím v použití snapshotu stavu dat ze začátku transakce pro všechna čtení, což v kombinaci s "optimistickým" přístupem vede v určitých situacích ke katastrofickým selháním (= transakce nebude schopna úspěšně dokončit práci NIKDY protože bude neustále rušena jinými, menšími a rychlejšími transakcemi měnícími stejná data).
Zbytečně se tu navíc ztrácí příležitost pro ostatní transakce změnit (a commitnout) změny dřív než budou data poprvé přečtena aktuální transakcí.
Snapshoty fungují dobře jen pro read only transakce které nemohou měnit data a mohou tedy předstírat že proběhly v nulovém čase.
Jasně že se to dá obejít explicitním zamykáním, ale o tom právě serializable model je - nemuset to dělat ručně ;) -
je to kompromis mezi hromadou kodu navic a funkcionalitou. Navic je otazka, zda-li MGA pravy serialisable rezim dokaze efektivne zajistit.
Ann Harrson "I've been out of the database design business since 1992.
Maybe Dr. Gray has understood the InterBase MGA concurrency control better since then. At the time, he didn't. I spent a great many hours between
1980 and 1992 (and a considerable amount since) trying to find the
trick to make MGA serializable - as have others, much more inspired
than I. My current belief is that the problem has no solution.
However, our goal was not academic purity, or even earning an A on
Date's quiz. It was to create a highly concurrent database that
provided acceptable consistency and predictable anomalies. Any
anomalies had to be avoidable through consistent programming practice
without significant performance cost. I think we succeeded."
This isolation level specifies that all transactions occur in a completely isolated fashion; i.e., as if all transactions in the system had executed serially, one after the other. The DBMS may execute two or more transactions at the same time only if the illusion of serial execution can be maintained. At this isolation level, phantom reads cannot occur.
With a lock-based concurrency control DBMS implementation, serializability requires that range locks are acquired when a query uses a ranged WHERE clause. When using non-lock concurrency control, no lock is acquired; however, if the system detects a concurrent transaction in progress which would violate the serializability illusion, it must force that transaction to rollback, and the application will have to restart the transaction.
Takze je hezke, ze serializace je definovana teoreticky, s praxi je to asi horsi.Mohu se zeptat, ktera databaze ma korektne implementovane serialisable transakce? -
Ony to umí skoro všechny. Oracle, MS SQL, Sybase... snad i mysql s innodb to umí.
Problém s tím mají jen databáze co používají různé formy snapshotů / optimistických schémat.
Jediný problém se serializable je ten že to stojí databázi práci. Jenže přenášet to na uživatele manuálním zamykáním je ještě horší ;) -
To by mne celkem zajimalo. Je k tomu nejaka dokumentace? Znam jenom PostgreSQL a Firebird. Co jsem si myslel, tak serializable transakce jsou hlavne definovane neexistenci Phantom Read. Jinak co vim, tak oracle (alespon 9 mela totez chovani jako PostgreSQL), tj transakce nemusi byt serializovatelna a pokud chci zabranit problemum, musim pouzit SELECT FOR UPDATE. Nicmene to uz je take nejaky rok zpatky. Na jedinou zminku ohledne pesimisticke strategie jsem narazil u Solidu http://www.mysqlperformanceblog.com/2006/09/22/test-drive-of-solid/
-
Firebird byl náhodou docela dobrej, jen měl tendenci postupně zpomalovat a zpomalovat při intenzivních updatech...
V ANSI X3.135-1992(R1998) co tu mám je na str. 54 napsáno:
The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.
The isolation level specifies the kind of phenomena that can occur during the execution of concurrent SQL-transactions. The following phenomena are possible:
Načež následuje popis Dirty read, Non repeatable read a Phantom read. Takže serializovatelnost není definovaná výskytem těchto jevů.
Taková definice serializable umožňuje dokonce víc než klasické dvoufázové zamykání - třeba využít efektu komutativních operací pro zvýšení paralelizmu transakcí.
Typický příklad by byl vyskladňování zboží - když bude jeden dost chytrý aby odečtení ze skladu napsal jako
UPDATE sklad SET pocet = pocet - ?mnozstvi WHERE id=?zbozi AND pocet>=?mnozstvia úspěch zjišťoval jen podle update countu příkazu aniž by se zajímal kolik ze přesně zboží na skladě je, vyhne se jevu hotspotu (transakcím hádajícím se o často měněná data)!Něco takového je v databázích stále ještě bohužel scifi :)
-
He he, a open vs. closed source je známka kvality? Co třeba projekt Firebird? S InterBase jsem se setkal poprvé s verzí 4 (cca 10 let, už tehdy měla uložené procedury a triggery, v té době se např. MS SQL o triggrech ani nesnilo), pak 5.5 a těsně před vydáním verze 6 byla uvolněna jako open source a vznikly dvě větve - Borland dále pokračova s InterBase a druhá větev je open source projekt Firebird. A nezdá se mi, že by tím utrpěl na kvalitě a zatím ani cca 40000 důchodcům, které vyplácíme, se nezdá, že by kvůli Firebirdu nebrali peníze.
-
Zbytečně nasíráš lidi. O Innodb se nedá říct, že to je primitivní filesystém, zrovna tak o Falconu. Triggery a uložené procedury nemají dotažené. Od svého vzniku popírali nutnost logiky na straně databáze, a teď nemají uživatele, kteří by je dokopali, k tomu, aby to dotáhli. Priority MySQL jsou někde úplně jinde. Taky uživatele MySQL jsou jiní než uživatele PostgreSQL. Bohužel rétorika MySQL vedla k tomu, že dost velká část programátorů nemá tušení o datovém návrhu, datové integritě, o možnostech, které mají databáze. Ale to je jiný problém.
MySQL se používá i pro velké projekty - ceny, které google zaplatil za svoje poslední akvizice odpovídají velkým průmyslovým kolosům. Narazil jsem na termín web centrické aplikace. -
Zero (neregistrovaný)Podla tej reklamy co bola na boku asi odporucaju radsej pouzivat MS SQL server:)
ale teraz vazne.. Je to sice robustny server, ale zase ako je zvykom MS nedodrzuje SQL standary... MySQL je sice mlady ale rychlo sa vyvyjajuci server, pre nekomercne pouzitie free a prave jeho mladost moze byt jeho vyhodou moze byt nasadzovanie novych technologii v sprave a uchovavani dat alebo cohokolvek, co sa tyka db a dat... ak chce BD vyuzit komercne, tak podla mna by siahol po oracle... -
uzivatel (neregistrovaný)To je dost mozne v niektorych veciach. No v niektorych castiach velmi kvalitne prepracovalo SQL normu do svojej podoby podla ktorej sa inspirovalo niekolko dalsich tvorcov, ako PostreSQL a SQLite.
Taka AUTO INKREMETANCIA, LIMITovanie zaznamov je nepoprednym zlepsenim oproti norme, samozrejme aj UNSIGNED moznost pri ciselnych hodnotach. Pri velkoobjemovych tabulkach prave takato moznost dokaze vo velkej miere usetrit miesto. -
Zero (neregistrovaný)Cize ak vytvorim nejaky komercny soft, ktory bude vyuzivat MySQL tak zan nemusim platit pri nasadeni toho softu a db v komernej sfere ci ako??? Ja som si myslel ze je to takto pytas za nasu DB prachy od uzivatela, tak daj aj ty prachy nam...
Tak nejako v skratke a polopatisticky :) -
McBig (neregistrovaný)ne, jde o licenci aplikace, ktera vyuziva mysql, tedy:
* aplikace je open-source a pod GPL - mysql je tez pod GPL, uzivejte zdarma kdo muzete
* aplikace je open-source ale ne pod GPL - mysql je pod GPL, uzivejte zdarma kdo muzete ,pozor ale na mysql, ta je stale pod GPL
* aplikace neni open-source a je vyzivana komercne - platte za mysql
jinak receno, pokud aplikace bude open-source, ale vy ji budete prodavat (coz samozrejme muzete), porad za mysql neplatite. A jestli sem to pochopil dobre, tak ani neplatite v pripade, ze mate hostingovy server, na kterem bezi mysql jako sluzba zakaznikum pro webove aplikace.
Tedy tato licencni politika dava jisty prostor pro pusobnost v komernim svete, aniz by ste musel platit mysql, ale neni to uplne tak idealni, jak by byt mohlo. -
anonymníA jestli sem to pochopil dobre, tak ani neplatite v pripade, ze mate hostingovy server, na kterem bezi mysql jako sluzba zakaznikum pro webove aplikace.
Tak tomu opravdu je, psal jsem jim asi pred dvema lety a potvrdili mi to. Tzn. pokud je MySQL soucasti vasi infrastruktury a nebundlujete to treba s nejakym produktem, tak nemusite platit. -
McBig (neregistrovaný)Souhlasim, licence by mohla byt o kousek lepsi :( Nicmene PostreSQL se me nelibi proto, ze pro vetsinu aplikaci je to proste kanon na vrabce :( Myslim ze resenim by mohla byt treba SQLite provedena client-serverovym zpusobem, coz si nedokazu dost dobre predstavit :)
Uz sem se chystal testovat firebird, ale instalace je porad proti mysql priliz krkolomna :(
A fakt, ze se s mysql pocita uplne vsude je jeho obrovske plus. PostgreSQL je dle meho nazoru hned druha. Da se to ale resit pres odbc driver, coz vnasi do ucelene prace preci jen vice volnosti v DB backendu ... otazka je za jakou cenu. -
Zero (neregistrovaný)Podla mna za cenu mensieho "spomalenia"(vecsich systemovych poziadavkov), ale v podstate to ten volnejsi DB backend vynahradi... takze ak robit nieco kde sa este neda odhadnut na akej db to pobezi tak jednoznacne cez odbc... predsa len to "spomalenie" pri dnesnych vykonoch serverov by sa prejavilo az pri nejakom takom projekte ako je google alebo sf.net
-
Zero (neregistrovaný)skus pomocou phpmyadmin ci ako sa to vola urobi to dump to txt suboru a potom by si to len importol... neviem ci to bude fungovat, lebo z MySQL do MSSQL to nejde MSSQL totizto nepozna typ date ale iba datetime a pri prevode na toto som vzdy narazil na problemy... ach tem microshit a standardy.. :(
-
Pokud mate novejsi phpMyAdmin umi i cosi jako export do kompatibilniho SQL nebo PostgreSQL. Existuje i skript ktery vam prevede mysql dump do postgresql - neni to 100% ale da se to - viz napr. phpBB MySQL -> PostgreSQL
-
uff, tak som si ten clanok precital;
z osmich "zvucnych" dovodov proti MySQL sa vyklulo 8 blabolov.
prvy dovod je, ze MySQL pouziva GPL, druhy dovod, ze nepouziva GPL. autor sa zrejme nevedel dohodnut sam so sebou. ano, existuju pripady, ked GPL nevyhovuje - hoci to nie je vseobecne uplatnitelna nevyhoda MySQL. to, ze pre firmy, kt nechcu redistribuovat svoj kod na baze MySQL pod GPL, existuje aj komercna licencia, za ktoru treba platit je asi ocividna nehoraznost.
treti bod hovori o "integracii" s existujucim prostredim - presnejsie o tom, ze ked ste si uz kupili nejaku inu DB, tak sa vam neoplati instalovat este aj MySQL. s tym v principe suhlasim, ale nie je to nic co by neplatilo vseobecne pre ktorukolvek DB. autor by si tiez mohol ujasnit pojem integracia.
v stvrtom bode rozobera "vyspelost produktu" (product maturity). ehm, na zaklade poctu rokov na trhu... (nu z tohto pohladu je aj firefox oproti msie len babatko bez prava na pouzivanie)
piaty bod - vyspelost funkcionality. v tomto nie som specialista, no cakal by som viac, ako konstatovanie, ze niektore funkcie su k dispozicii len v poslednej verzii.
6 - dostupnost certifikatov. hm, absolvovat trening s peciatkou sa neda na tolkych miestach ako pre Oracle/MSSQL. to vazne ubera vykonu databazy...
7 - korporatne zazemie. hm, nemozete si kupit akcie fy. MySQL AB. to niektorych manazerov vystrasi k smrti...
8 - "vnimanie skalovatelnosti". autorovi sa nepaci, ze MySQL vyzdvihuje svoju horizontalnu skalovatelnost (viac serverov) a nespomina vertikalnu (silnejsie servery). FUD. iba ak by bola uvedena studia, ktora ukazuje, ze MySQL nedokaze vyuzit viacprocesorove stroje, akceptoval by som to ako pripomienku nevyhodnu v niektorych prostrediach (specialne tam, kde je v serverovniach malo miesta a maju bohate IT oddelenie - (viacprocesorove stroje su zvycajne drahsie ako viac menejprocesorovych - pri rovnakom pocte CPU & RAM. plati napr. pre HP, Sun))
sice je mile, ze autor ten clanok napisal vo vi, ale publikovat ho teda nemusel.
na root.cz by bolo tiez celkom fajn, keby spravicky uvadzali hodnotnejsie zdroje - keby autor aspon precital odkazovany text - aj ked aspon je diskusia :) -
Vyjadrim se pouze k poslednimu bodu, ktery se me bezprostredne tyka - ano, je to samozrejme pravda, nicmene kolega ma dovolenou, tedy mam celou redakci na starost ja, coz je na jednoho cloveka hodne prace, nez abych jeste stihl detailne studovat kazdy clanek ktery linkuju jako zpravicku. Podotykam, ze pri tom vsem se jeste snazim studovat.
-
ad 3) Ano. Da se to rict o vetsine SW, ktery je nutne nejak zakomponovat do stavajicich firemnich technologiich. To ale jeste neznamena, ze to neni duvod proti.
ad 4-5) Pravdou je, ze pred MySQL5 tomuto SRBD chybelo par podstatnych veci jako triggery a rozumna podpora storovanych procedur. To mohlo rade aplikaci vadit (udrzovat konzistenci nad celou databazi pomoci aplikacni logiky neni moc cista cesta). Takze vyvoj jeste urcite potrebuje a je pravda, ze v 5. verzi se vyvojari docela pochlapili :)
ad 6) To ne. Ale provoz SRBD neni jen vykon. Take ho potrebujete administrovat a certifikaty pomahaji zamestnavateli k lepsimu vyberu a tim padem i levnejsimu 'provozu' administratora.
ad 8) No, zvlaste na profesionalnich housingach, kde se plati predevsim pozice v racku, muze byt mnohem vyhodnejsi poridit viceprocesorove masiny. A jestlize mate napr. webovou sluzbu a databazi na jedne masine, bylo by dobre, aby aplikacni server i databaze mely kazdy svuj procesor a v pripade, ze 'ten druhy' ted nepracuje, vyuzit zbyly vykon. To uz je ukol pro 4-procesorovou masinu.
A licence pro vice procesoru by obecne mohla byt levnejsi, nez vice 1-procesorovych. Ted mluvim jak o OS, tak o SRBD.
Dale je tu jednoduchost administrace. Jestli mam administrovat 4 4-procesorove stroje, nebo 16 1-procesorovych .. vedel bych, co si vybrat. -
> 8 - "vnimanie skalovatelnosti". autorovi sa nepaci, ze MySQL vyzdvihuje svoju horizontalnu skalovatelnost (viac serverov) a nespomina vertikalnu (silnejsie servery). FUD. iba ak by bola uvedena studia, ktora ukazuje, ze MySQL nedokaze vyuzit viacprocesorove stroje, akceptoval by som to ako pripomienku nevyhodnu v niektorych prostrediach (specialne tam, kde je v serverovniach malo miesta a maju bohate IT oddelenie - (viacprocesorove stroje su zvycajne drahsie ako viac menejprocesorovych - pri rovnakom pocte CPU & RAM. plati napr. pre HP, Sun))
MySQL skutecne ma problemy s viceprocesorovymi stroji. Na vine jsou bugy v innodb, a v malloc, ktere se v MySQL pouziva, Ty studie jiz byly provedeny:
http://tweakers.net/reviews/657
http://tweakers.net/reviews/657/6
http://ozlabs.org/~anton/linux/sysbench/
Na druhou stranu koho to zajima. Dobre napsane aplikaci s vyladenymi sql dotazy staci jednoprocesorova p4. MySQL ma dnes podstatne lepe vyresene replikace plus jakys takys clustering. PostgreSQL je zas lip vyladena pro velke servery se specialnim hw.
Me osobne vic vadi ryze komercni chovani MySQL k navrhum komunity. V podstate, pokud chcete nejake rozsireni v MySQL, tak si jej musite a) napsat sami, b) musite zaplatit MySQL za integraci. Pred rokem a pul jsem s kamaradem posilal patch opravujici nekorektni lokales pro kodovani 1250 (tedy zadny pozadavek na dalsi vlastnost, ale opravu chyby). Do dneska to v core neni. PostgreSQL je podstatne otevrenejsi, v okamziku, kdy jim poslete patch, tak pokud je akceptovany, tak je aplikovan do nekolika dnu. -
prvni nastrel. Reagovali tak, ze to daji do dalsi verze, pak do dalsi, nicmene zatim se tak nestalo. Kodovani win1250 je zjevne netankuje. Kde tam jsou ceske komentare? Mozna tam neni link na posledni verzi. http://lists.mysql.com/internals/33393
-
McBig (neregistrovaný)*** mysql-5.0.17/strings/ctype-czech.c
--- 165,172 ----
Na konci připojíme znak 0
*/
+ /* treti kolo je case sensitive */
Ale v tom poslednim uz neni :( :D Je to skoda, i kdyz uprime receno, utf je utf, a je to preci jen maly donucovaci prostredek k tomu, aby na nej uzivatele presli ;) -
uzivatel (neregistrovaný)Akoze nechcem prudit, ale WIN-1250 ? Chapem, ze je to naozaj pekne opravit urcitu chybu v DB systemu, ale priznajme si. Kolko webovych sluzieb ma v backende kodovanie win-1250. Ja ked som zacinal s DB a to som nemal ani trochu potuchy ako to pracuje (klasika v. 3.23) tak mi bolo jasne, ze lepsie je uz pouzivat normovane kodovania v tej dobe ISO-8859-X. Predsa drviva vacsina vtedy aj teraz fici na Linuxe
-
Cim dal tim min webu pouziva 1250, nicmene v zacatcich drtiva vetsina mysql databazi bezela v 1250. Na bug se prislo pri testovani prechodu na 5.0. Zastarale kodovani neni duvod pro toleranci bugu. Budto maji stahnout podporu tohoto kodovani nebo jej maji podporovat korektne. Proto jsme se to take zkouseli opravit a systemove resit zaslanim patche do MySQL. Tam na nas ovsem zvysoka ... takze nezbylo prejit na latin2. O samotne kodovani nejde, tam vetsinou nejsou problemy. Chyby se objevuji v navaznych aplikacich, ktere se po deseti letech pocitaji na desitky. Vzhledem k dynamickemu rekodovani neni tak dulezite ani vnitrni kodovani, za predpokladu ze MySQL je nainstalovano korektne. Viz stale stejne problemy, kdy MySQL je nainstalovano pro latin1 nicmene data uvnitr jsou v latin2 nebo v 1250. Bohuzel takovych mrch je neskutecne.
-
uzivatel (neregistrovaný)No s prechodom na verziu 5 tato chyba uz naozaj nema opodstatnenie. Pokial si spravne myslim tak verzia 5.0 vsetky data uchovava v Unicode a Collate je len prevodova funkcia, ktora prelozi Unicode na zvoleny jazyk a opacne.
Naozaj nevidim ziaden problem pouzivat UTF-8. Niektori budu urcite namietat tym, ze oproti lokalnym kodovaniam ma dvojnasobnu velkost, no nie je to tak pravda. 8bitove znaky pouziva pre definovanu ASCII tabulku a tie ktore sa v nej nenachadzaju tym padom maju 16 bitov.
Na to, ze je na vacsine serverov definovany collate pre latin1 je chyba adminov. Prave latin1 je ako prvy v zozname tychto collateracii a lenivym administratorom sa to nejako nechce prehadzovat na nieco normalnejsie. -
Izak (neregistrovaný)MySQL je dobra databaze, na to na co byla urcena, to jest de fakto inteligentni disk s minimem zapisu a mohutnem cteni.
Nato je MySQL super, nebot tim ze toho malo umi, to malo dela skutecne rychle.
Na skutecne vytizeny server, s mnozstvim zapisu a mnozstvim cteni, zajisteni integrity dat a replikaci patri PostgreSQL popr rozsireny o Slony ... 1 server pro zapis a cluster pro vyhledavani.
Na PostgreSQL dokonce existuje proxy, ktera udela ze dvou serveru mirror, klient komunikuj s proxy a ta zapis dava na oba nody naraz a cte jen z jednoho a jeste to rozhazuje. -
Z company (neregistrovaný)>Na skutecne vytizeny server, s mnozstvim zapisu replikaci patri PostgreSQL popr >rozsireny o Slony ... 1 server pro zapis a cluster pro vyhledavani.
Sorry ale Slony1 je nepouzitelne pokud je do databaze vice zapisu. Slave uzly nikdy nedohoni master.
Protoze:
1. fetchuji se radky ve skupinach po 100 misto pomoci COPY. Potreba poeditovat zdrojaky a vrazit tam aspon 1000. To ale odmita dev. team komitnout i kdyz jim to lidi v ML cas od casu mlati o hlavu.
2. vyzaduji se vicemene syncnute hodiny + timezona mezi servery
3. ma to race conditions a je potreba cas od casu rucne editovat katalogy
4. Jeden SQL statement na masteru to rozlozi na mnoho SQL statementu na slave uzlu (jejich provadeni je o mnoho pomalejsi)
5. Koncepce listen/notify eventu je zbytecna, stacilo by jen delat poll, protoze vzdycky tam nejaka nova data budou.
6. Nema optimalizaci fetchnutych dat pred jejich nacpanim do DB a ani nepouziva prepared statementy - delani zmen v lokalni db je proto znacne pomale.
7. ma to bugy, ktere i kdyz jsem nekolikrat reportoval a jsou to oneline fixy zustavaji porad nefixnuty
8. skalovatenost s poctem serveru v clusteru O(N*N)
9. Prepinani log segmentu je velmi brain damaged, navic segmenty jsou pouze 2, coz znemoznuje delat droptail optimalizaci tohoto procesu.
Slony1 je pouzitelne pouze pokud je na masteru *malo* zapisu. Slony1 by mohlo byt lepsi kdyby se na tom delalo ale protoze autorum to v produkci bezi na read mostly aplikaci, tak to fixnuty nebude nikdy, neni vule s tim neco delat. Kdyz neni vule autoru s tim neco delat tak zjevne Open source koncepce nefunguje.
Proto taky vznikaji nove replikacni projekty pro pgsql. Jejich developeri pochopili, ze cas spostrebovany v diskuzich na slony ML se da efektivneji vyuzit pro kodovani vlastniho systemu.
Taky jeste slony1 instalace pouzivam, ale uz ho nepouzivam pro nove projekty. Jsou lepsi reseni. Jedno sponzoruji. -
1. kvalita JDBC driveru, MySQL ma lepsi
2. kvalita replikace, MySQL ma lepsi replikaci nez je Slony1
3. nefunkcni PL/Java - leakuje to memory a s 8.2 to nejde vubec
4. rollforward recovery proces je opravdu velmi hardcore
Problem je v tom, ze autori PGSQL chapou DB jako samostatny produkt. Ale mit dobrou databazi nestaci, je nutne k ni mit jeste dobre, nebo alespon pouzitelne ty nejbeznejsi drivery. t.j. jdbc a odbc a replikaci. Funkcni PL/Java by bodla taky.
Jsou aplikace, kde to sice neni potreba, ale v EE aplikacich to potreba je. Tam se bez replikace vubec nehnete protoze provoz 24/7 je nutnosti.
Jednak 8.3 pgsql je opravdu kvalitni vyrobek (funkcionalita uz je temer na urovni Oracle8i - rekl bych ze uz se Oraclu 8 vyrovna), ale chtelo by development zdroje misto vyroby pgsql 8.4 presunout do oblasti EE. Nakodovat kvalitni JDBC, PL/Java a replikaci. Coz je utopie. Kodovani vlastniho DB serveru a soutezeni s MySQL kdo bude mit lepsi vykonostni grafy je vice sexy.
