Vlákno názorů k článku Transakce a izolace transakcí v databázích od Substance242 - Ale ja som na Radkovom najčítanejšom blogu na...
-
Substance242 (neregistrovaný)Ale ja som na Radkovom najčítanejšom blogu na svete čítal, že MySQL je strašne zastaralé a dobré akurát tak na nejaký malý CMS a tak... hmm? :-) Napríklad že nemá triggery, aj keď priznám sa že neviem čo to je.
PS: Článok som si vytlačil a prečítam si to v pokoji neskôr... ale vyzerá dobre. -
No je pravda, že MySQL nemám rád, protože neumí spoustu věcí, na které jsem z Firebirdu zvyklý (stored procedury, které umějí vracet datasety, triggery, check constrainty atd...) a také dělá věci, které bych nikdy nepředpokládal (např. vztah mezi not null constraintem a default hodnotou sloupce). Možná je to tím, že MySQL moc nepoužívám (1. jen krátce, 2. snažím se mu vyhnout a radši nasadit Firebird) a tudíž s ním nemám moc zkušeností. Ve FB jsem poměrně kovaný, takže jsem schopen řešit spoustu problémů tak nějak automaticky. A pro rýpavé podotýkám - MSSQL nemám rád také :-) -
Počínaje 5.0 MySQL umí řadu věcí, které jste jmenoval - uložené procedury, které dokonce vrací multi record sets, triggery, check constrainty. Akorát málo kdo to používá :(.
http://www.root.cz/clanky/letmy-uvod-do-ulozenych-procedur-mysql-prvni-cast/
http://www.root.cz/clanky/ulozene-procedury-event-scheduler-a-informacni-schemata-mysql/
Má to určité mušky, ale je to použitelné. -
Pracuji právě s verzí 5, ale má to opravdu hodně mušek :-(
Ty triggery mi trošku ujely a datasety ze stored procedur jsem nevěděl jak na ně (no muset vytvořit temporary tabulku pro vrácení datasetu ze stored procedury mi přijde jako drbání se levou rukou za pravým uchem a prostrčit si ji při tom ještě mezi nohama :-)).
Na mě působí MySQL asi tak, jak bylo řečeno v titulku Vašeho článku - rychlé, ale ne 100% spolehlivé, nepodporující některé nejzákladnější postupy. Co jsem zatím viděl, tak MySQL je DB, kterou využívají především lidé, kteří dělají weby pro ukládání takovýchto dat (mám na mysli data jednoduchá - nic extra komplexního). A z těch databází, které jsem od těchto lidí viděl, mi nebylo moc do zpěvu (absence základních návyků, postupů a pravidel při vytváření, nelogičnost, duplicity atd...).
P.S.: Patřím mezi lidi, kteří se bez transakcí neobejdou :-)
P.P.S.: Check constrainty v dokumentaci verze 5.1 prostě nevidím. -
Omlouvam se za mystifikaci. InnoDB podporuje pouze foreign key constrainty - klasicke CHECK ignoruje. Spojil jsem si je dohromady.
Ohledně vracení datasetů MySQL věrně kopíruje MS SQL. Přijde na to. Někdy je výhodnější připravit generované množiny hromadnými operacemi (ala MS SQL nebo MySQL) někdy po řádcích (Firebird, PostgreSQL). Co se týče syntaxe, tak snad vyjma nové Sybase, žádná databáze nerespektuje standard. Věcně je způsob MS ale standardu relativně blízký.
MySQL AB to s 5.0 docela zazdila. Chtělo to ještě rok počkat a ty uložené procedury dotáhnout. Lidi se na 5ku docela těšili, a pak zjistili, že třeba ohledně uložených proc, předložená verze odpovídá zhruba prototypu. Přesto se našlo pár lidí, kteří proc používali a propagovali:
http://rpbouman.blogspot.com/
http://db4free.blogspot.com/2005/11/calculate-uniqueness-of-text-fields.html
MySQL AB se pak věnovala víc replikacím a pak bohužel utopila hodně energie ve Falconu. Což může být zajímavý engine. Zatím ovšem po třech letech je v hrubé betě. -
Co mě mrzí, je to kopnutí si do MySQL na začátku. Technický článek s politickým začátkem docela znechutí.
Jinak já vím, co jsou to transakce dobře, dělal jsem s velkými dbms ještě před tím, než jsem potkal MySQL, a sice jsem chvíli nadával, ale všude je něco, s čím se zápasí. V PostgreSQL se zápasilo s chybovostí až vysokých verzí, teprve až poslední roky se dá na PostgreSQL spolehnout, že nelikviduje data. A to nemluvím, jak dlouho PostgreSQL trvalo, než byla schopná poskytnout Windows port, což také leccos říkalo o schopnostech jejích vývojářů a o tom, jak byla programovaná. Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód. U Firebirdu se zase zápasí s nejhorší dokumentací co u projektu znám, a u dbms to bolí desetinásobně. To jen na vyváženost.
Jinak u MySQL bych opravil – triggery jsou tam napůl nepoužitelné. Triggery nesmí měnit tabulku, nad kterou sedí, což je z hodně použití (neříkám že ze všech) diskvalifikuje.
V zásadě bych řekl, že triggery v MySQL mají největší použití právě jako náhrada constraintů, protože umějí odmítnout sql příkaz. Možná tak byly i míněny.
Jinak s tím, že MySQL 5 vyšla předčasně bych se ztotožnil.
Ohledně Falconu, oni neměli jinou možnost, než potápět InnoDb a rozvíjet Falcon. InnoDb totiž nebyl jejich engine, a firmu InnoDb software koupil před časem Oracle, který jim mohl kdykoli zavařit a odepřít pokračování v poskytování InnoDb. Právě proto začali horečně rozvíjet nový, svůj vlastní engine Falcon a moc doufali, že jim Oracle nepřidusí vzduch, než ho dokončí. Ironií osudu je dnes MySQL v rukách Oracle, takže možná se změní celá strategie MySQL, kdo ví, každopádně se dá čekat leccos – od dobrých až po špatné zprávy. -
To není kopnutí - ale připomenutí. Určitě se na tu dobu pamatujeme oba. Diskuze zda transakce ano či ne se rozhořela právě ohledně MySQL. Do té doby se transakcím nikdo zvlášť nevěnoval. Podobné diskuze běžely paralelně třeba ohledně referenční integrity nebo použití uložených procedur (namátkou právě třeba triggerů). Jakási filozofie každého produktu pak samozřejmě ovlivňuje i jeho vlastnosti - díky tomu MySQL má stále třeba určité problémy s uloženými procedurami a například PostgreSQL dodnes nemá integrovanou replikaci. Prostě každá parta vývojářů měla a má jiné priority - proto třeba PostgreSQL dlouho nebyl pro Windows (nekomerční varianta PostgreSQL - komerční porty na Win - bylo jich několik - předcházely finálnímu portu možná i pět let).
Souhlasím, že koupě InnoDB Oraclem byla pro MySQL AB rána, která poslala MySQL do rukou Sunu a následně neplánovaně Oraclu. Vývoj Falconu sebral určitě hodně energie a zdrojů - nedávno jsem narazil na zprávičku o ohlášení Falconu starou tři roky - předpokládám, že to nečekali, když pro vývoj engine angažovali Jima, který do MySQL přišel s vlastním již existujícím enginem. Je jen otázkou, jak by MySQL vypadala dnes, kdyby se vývojáři nemuseli věnovat vývoji Falconu. -
Zdenek Kotala (neregistrovaný)
Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód.
Jednak Borlandu trvalo nekolik verzi, kdy kod na widows stabilizovali. Prvni pouzitelna verze defakto byla Interbase 6. A co se tyce kodu videl jste ho nekdy? Az posledni verze se daji jakztak prelozit a funguje ./configure. Ale prelozit takovy firebird 1.0 se v podstate nedalo. Zdrojovy kod neni vubec dokumentovany a zoreintovat se v nem je dost narocne. Naproti PostgreSQL je jeden z mala kodu, ktery jsem mel moznost videt, v kterem se da velice dobre orientovat a je dobre dokumentovany.
-
Já řeknu toto: Zdrojový kód MULTIPLATFORMNÍHO programu, který byl přes 20 let vyvíjen, prošel rukama několika vývojových týmů – od toho bych nečekal dokonale čistý kód. Mluvím o Firebirdu. Zřejmě nečekáte, že v těch letech se vyvíjelo nad configure, a ve Windows se takto také nevyvíjí. Navíc není příliš zvykem (a hlavně v minulosti nebývalo zvykem) psát extra dokumentaci pro relativně malý projekt uvnitř vývojového týmu – což byl případ Interbase.
Možná Vám to ušlo, ale pro jistotu bych Vám rád připomněl, že Interbase byl komerční projekt, který byl vyvíjen uzavřeně a interně. A když byl tuším někdy po roce 2000 darován Borlandem open source komunitě, dokumentace tomu odpovídala.
Mimochodem, právě dokumentace je dokonalým důkazem neshcopnosti open source vývoje Firebirdu. Jediná rozumná dokumentace, od které se můžete odpíchnout je manuál psaný Borlandem. Nějaká ucelená a rozumná dokumentace pak od open source vývoje neexistuje, takže celkem není divu, že Firebird postupně upadá do zapomnění. A možná, že celá 28-letá historie Firebirdu dopadne tak, že o jeho likvidaci se postará až open source komunita zanedbávající dokumentaci tak brutálně, jak se to jinde nevidí.
PostgreSQL je mladší projekt, než Firebird/Interbase, a také s multiplatformovostí měli dlouho velmi výrazné problémy. Že je kód přehlednější, když prostě natvrdo (tedy nemultiplatformně) volali UNIX api, to je celkem nabíledni spolu s mladším stářím projektu a otevřeným stylem vývoje. -
Ksl (neregistrovaný)
Mimochodem, právě dokumentace je dokonalým důkazem neshcopnosti open source vývoje Firebirdu. Jediná rozumná dokumentace, od které se můžete odpíchnout je manuál psaný Borlandem. Nějaká ucelená a rozumná dokumentace pak od open source vývoje neexistuje, takže celkem není divu, že Firebird postupně upadá do zapomnění. A možná, že celá 28-letá historie Firebirdu dopadne tak, že o jeho likvidaci se postará až open source komunita zanedbávající dokumentaci tak brutálně, jak se to jinde nevidí.
Čtete firebirdí Release Notes? Přijdou Vám nějak neúplné nebo nedostatečné? Já myslím, že jejich editorka odvádí výbornou práci. Aha. Já zapomněl. Vy si nechcete koupit její knížku, přestože ta kniha je tisíckrát lépe napsaná než celá ta slavná dokumentace k PHP a MySQL. :-) -
Zdenek Kotala (neregistrovaný)
No mne nic neuniklo. To vy jste tvrdil:
Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód.Tak si to nejdrive ujasnete vy co je Firebird a Interbase, kdyz mne to pak omlacujete o hlavu. Co ja tvrdim je to, ze neni pravda, ze to bylo jednoduche, jak si myslite a trvalo to nekolik verzi(let) nez se to zadarilo.
Dale bych Vas rad upozornil, ze neexistuje nic jako UNIX api. Existuje neco cemu se rika ANSI C a POSIX. Obe tyto normy slouzi k tomu, aby bylo mozno psat prenositelne aplikace. To ze na windows POSIX api je rozbite to je proste fakt a pak je nutne si ho tam dopsat.
Dale bych Vas rad upozornil, ze Postgres tak Interbase vznikali obe v 80. letech takze tvrzeni, ktera databaze je mladsi je irelevantni.
ČLÁNKY DO MAILU