MySQL: další obstrukce Oraclu? (diskuse)

[Pooky]

Patrně je čas, podívat se po jiné databázi... Co Oracle uchopí do pracek, to buď zpoplatní a nebo zadupe.

[tomas]

vsak kvuli tomu tady je mariadb ne?

[Pooky]

Také jsem o ní slyšel ale v depozitářích zatím nějak nezakotvila.

[Pooky]

* repozitářích (blbé opravy)

[kavol]

zakotvila :-p

[w4rr10r]

MariaDB, Percona Server,... Drizzle, PostgreSQP.

[pp]

forknete to nekdo uz

[Lol Phirae]

http://mariadb.org/

[TM]

To mě fascinuje... ta naivní víra, že cokoliv někdo "forkne" a vývoj bude pokračovat dál.
Zkušených vývojářů databázových systémů je dost málo, takže se dá těžko čekat, že bude existovat srovnatelná OSS verze MySQL po jejím případném uzavření. Předpokládám, že většina současných autorů MySQL jsou momentálně dobře placení zaměstnanci Oraclu...nebo je to jinak?
Pokud OSS náhradu za případně uzavřenou MySQL, pak PostgreSQL - byla vždy daleko lepší.

[w4rr10r]

A co takhle se po tom podívat? Percona udržuje fork zaměřený na stabilitu a poskytuje k němu podporu. MariaDB se vyvíjí a měla by být z 97 % (dostačující pro většinu aplikací) kompatibilní s MySQL, pracují tam i dřívější vývojáři MySQL, probíhá komunikace s komunitou.

PostgreSQL je fajn, ale většina hostingů to nepodporuje a nepodporují to ani CMS (pokud ano, pak vesměs experimentálně, takže je to pomalé a plné chyb).

[retro]

No někdo používá DB na wordpress někdo zase na pořádnou práci. To že si na hosting někdo instaluje CMS v PHP s MySQL je opravdu každému vývojáři uplně jedno.

Příště se buď zdrž laciných komentářů bez znalosti tématu nebo se vyjádři pořádně.

[Václav HFechs Švirga]

Jediný laciný komentář, který tu čtu, je ten tvůj .

[retro]

Další laciný komentář. Kdybys napsal alespoň co není pravda či s čím nesouhlasíš.

[Lol Phirae]

Patláma matláma paprťála bžďuch.

[Václav HFechs Švirga]

+1

[retroslava]

Gratuluju. První den s počítačem?

[Václav HFechs Švirga]

Jelikož téměř 50 % obsahu tvého komentáře je navážení se do komentáře předdiskutéra a zbytek nějaký zmatený povzdech o 'pořádné práci TM', jde to těžko .

[cita]

nojo jenze percona i maria na to stejne dojedou.... nebudou mit testsuity k novym featurkam

[JoHnY2]

Proto jim to udelali. Na druhou stranu: Ty na MySQL vyuzivas nejaky novy featury? Me obecne staci to co umelo MySQL 5.1. Na komplexni veci tu mame Postgres a vic me MySQL netizi. Podle me se celej projekt na delsi dobu dostane do konzervovany podobny a pak se but MariaDB a spol. povede pretahnout linuxovy distribuce nebo nepovede.

[miso]

Nevidim do toho, ale mal som pocit, ze mysql-test sluzi na odhalovanie regresii - takze mozny "pruser" aj starej funkcionality.

[Honza Jaroš]

No já do toho taky nevidím, ale testy z předchozích verzí MySQL snad stále ještě k dispozici jsou, ne?

[Ivan]

Nevite nekdo jak je na tom storage engine Falcon? Uz to nekdo realne pouziva?

[okbob]

Vývoj Falconu byl ukončen - poté, co MySQL bylo převzato Sunem - detaily neznám - měli tam docela dost problémů - a to ať s výkonem nebo s kompatibilitou. Rozhodně se to nedostalo do stavu, kdy by to bylo možné nasadit v produkci.

[Miloslav Ponkrác]

Falcon ztratil smysl a tak se o něj nikdo nestará.

Byla nebyla jednou firma Sun. Ta koupila MySQL a součástí MySQL, milé děti, je InnoDb storage. Jenže InnoDb kód patřil firmě Oracle a ačkoli Oracle nedělala žádné problémy, byl to potenciální Damoklův meč. Oracle kdykoli mohl říct dost a odejmout licenci na InnoDb firmě Sun a tím by byla MySQL v loji.

Začali tedy v Sunu panikařit a vymysleli, že se InnoDb výhledově zbaví. A to tak, že napíší Falcon a nahradí jím InnoDb. Dlouhé roky firma Sun kašlala i na opravování závažných chyb v InnoDb a MySQL měla mnoho nepříjemných bugů.

Jenže co se nestalo, milé děti. Jednoho dne koupil Oracle MySQL. Jistě uznáte, že další vývoj Falcona, jehož smyslem mělo být zbavení se InnoDb aby Oracle nemohl ohrozit MySQL, ztratilo smysl.

Jelikož InnoDb vlastní Oracle, MySQL vlastní Oracle, tak není proč vyvíjet náhradu za InnoDb, tedy Falcon. Jinak řečeno, Falcon ztratil smysl své existence, ztratil se důvod, proč by vůbec měl být, proč do něho investovat.

Zazvonil zvonec a pohádky je konec.

Miloslav Ponkrác

[okbob]

Akorát, že v reálu je to trochu jinak - InnoDB zkoušelo koupit ještě MySQL A.B. - nicméně Oracle podal nabídku, které se nedalo odolat - čímž se InnoDB dostalo do rukou Oracle - načež Monty najal Jima, který k němu přišel už s rozdělanou databází, kterou v MySQL nazvali Falcon a z velkou slávou připravovali verzi 6. Jenomže se ukázalo, že nejsou sto dát falcona dostat do produkčního stavu - nevím jestli kvůli rychlosti nebo nekompatibilitě s InnoDB - a 6.0 se odsouvala - až do doby, kdy z velkou slávou koupil Sun MySQL. Jednou z prvních věcí bylo odejití Jima a ukončení vývoje Falconu - vývoj Falconu ukončen Sunem nikoliv Oraclem.

"Dlouhé roky firma Sun kašlala i na opravování závažných chyb v InnoDb a MySQL měla mnoho nepříjemných bugů" - Sun vlastnil MySQL cca rok, dva - přičemž pod taktovkou Sunu vznikla 5.5 a částečně 5.6.

[Miloslav Ponkrác]

V čem je to co jste napsal v rozporu s tím, co jsem napsal já?

Jednoduše jsem napsal, že InnoDb vlastnil Oracle a proto se snažili napsal Falcon. Neviděl jsem důvod, proč z toho dělat vědeckou práci a začít u pračlověků a v době prvohor. Jednoduše jsem odpovídal, proč Falcon byl odpískán.

Nerozumím větě „akorát to bylo v reálu trochu jinak“ – když to co píšete Vy je zcela v souladu s tím co jsem napsal já. Nenapsal jste ani čárku, která by odporovala mému příspěvku. Zřejmě je to nějaký jiný, okrajový význam věty „akorát to bylo v reálu trochu jinak“, který neznám.

To samé platí o druhém odstavci.

[okbob]

Primární rozpor je v tom, že vývoj Falconu začal ještě v MySQL A.B., což byla mateřská firma MySQL a byl ukončen poměrně brzo Sunem, ještě dříve než je koupil Oracle. Tudíž celá Vaše pointa nemá smysl - Falcon nebyl zaříznut kvůli konkurenci InnoDB.

[Miloslav Ponkrác]

Do háje, já jsem nenapsal, že byl Falcon zaříznut kvůli konkurenci InnoDb.

Já jsem jasně napsal a nikdy jsem nepsal nic jiného, že Falcon začal být vyvíjet kvůli tomu, že InnoDb vlastnil Oracle (od roku 2005, tedy 3 roky před prodejem MySQL Sunu). A protože nebylo jasné, zda Oracle neudělá nějakou protiakci, tak se začal se strachu a z pocitu že mají hnědé kalhoty na zadní straně z licenčních problémů, které jim mohl Sun udělat, tak začali vyvíjet Falcon, který měl InnoDb uvnitř MySQL zcela nahradit.

Jakmile MySQL získal Oracle, tak samozřejmě nebyl důvod dále vyvíjet Falcon. Oracle InnoDb vlastní, takže nepotřebuji vyvíjet NÁHRADU za InnoDb, kterou Falcon byl.

Falcon sice vyvíjelo MySQL A.B., ale první prerelease ukázal a poslal až Sun v roce 2009. Jinak řečeno, Falcon se do povědomí dostal až u Sunu.

Jim Starkey, který byl najat na to, aby naprogramoval Falcon zdrhnul dříve, než práci dokončil. Nebýt Starkeyho, je otázkou, zda by se vůbec ve firmě do Falcona pustili.

Jim Starkey, který vymyslel princip multiverzování namísto zamykání – což je významnou vlastostí databáze InterBase, dnes spíše známá pod forkem Firebird. MySQL se těšilo a v zásadě získalo jako vlastník optimismus, když ho najímali, že dokáží udělat dobrý storage engin, který vlastnosti bude schopen nahradit velmi dobrý InnnoDb. Jenže Starkey to nedodělal a zdrhnul před dokončením.

Sluší se ještě říci, že MySQL se pokoušela integrovat řadu enginů a databázových storage a postupně je mazalo.

A prosím, když budete příště tvrdit, že se mnou nesouhlasíte, uveďte něco, co je odlišné od toho co tvrdím já. Nebo napište, že mě nemáte rád a chcete mě prostě zpucovat a já to pochopím.

[Heron]

Kupodivu to ale u mnoha projektů funguje velmi dobře. PostgreSQL je špičková DB, ze které si své vyzobává i DB2 (například KNN Index), přestože, nebo právě proto, že je to open source. MariaDB je na tom dneska lépe, než MySQL. Jsou i další forky nebo i úplně jiné SQL i (Not Only)SQL DB. Zrovna v oblasti ukládání dat je OSS projektů požehnaně.

Ať si to Oracle klidně zavře do trezoru, svět si poradí.

[Miloslav Ponkrác]

Oracle vede MySQL velmi dobře. Rozhodně lépe, než Sun. Sun zanechal mnoho závažných bugů neopravovaných celou dobu jeho vlastnění MySQL. Oracle také dotáhnul featury vymyšlené Sunem.

V MySQL 5.5 nasadil výrazně lepší verzi InnoDb kódu s vyšším výkonem a lepšími vlastnostmi.

MySQL 5.5 navíc konečně umožňuje uložit unicode řetězce i v ucs4 a konečně umožnuje ukládat i unicode řetězce se znaky nejenom v základní rovině.

Musím říci, že MySQL se konečně dá používat. Předchozí Sun nebyl schopen bez chyby dát ani dokumentaci (například v chm souborech chyběly běžně stránky). Sun soutěžil na počet nových featur, ale počet závažných chyb se neustále zvyšoval. Teprve Oracle dal vše do pořádku.

---

Jinak asi i chápu, proč Oracle začal omezovat komunitu. Hlavní impuls přišel od PHP, které obešlo jeho licenci k libmysql tím, že si napsalo vlastní implementaci této knihovny pod názvem mysqlnd.

A to i přesto, že PHP to dělat nemuselo. Oracle dal na MySQL projekt GPL licenci + FOSS výjimku, která se vztahuje na PHP licenci.

A PHP je hlavní reklama a hlavní promo MySQL.

Čekal jsem, že na to Oracle nějakou represí či schválností zareaguje.

Miloslav Ponkrác

[okbob]

Blbost - tahle pohádka je posunutá o jednu generaci - dlouhá léta MySQL vlastnilo a vyvíjelo MySQL A.B. - pak MySQL bylo koupeno Sunem - načež se začalo skutečně s inženýrským vývojem - po roce - roce a půl byl Sun koupen Oraclem a ještě rychle se vydala verze 5.5 bo se nevědělo, co s MySQL provede Oracle. Hromada lidí ze Sunu, které dělali na MySQL rychle z Oracle odešli a začali dělat na forcích MySQL - MariaDB, PerconaDB.

[Lol Phirae]

Klid, jsou servery, kde Ponkrácovy bláboly rovnou mažou.

[Lol Phirae]

No, a jak tak vidím, tak po zablokování dotyčného se krásně pročistí diskuse i tady. Uff to je úleva.

[Miloslav Ponkrác]

Přesto je to tak, jak píši.

Vím, že Sun nebyl prvním vlastníkem, ale je zbytečné chodit do minulosti tam, kde to k vysvětlení není potřeba.

Sun se snažil vydávat mnoho featur, a měl předem daný časový plán, kdy musejí vyjít. A vyšly, nedoladěné, pokud se nestihlo.

Kromě toho se neopravovalo mnoho bugů v InnoDb části, protože se plánovalo, že InnoDb bude kompletně zrušen a nahrazen Falconem (viz můj příspěvek výše).

V době, kdy MySQL měl Sun počty chyb v MySQL narůstaly. Na zahraničních serverech se množily články a blogované zápisky, kdy z toho lidé byli zoufalí – spolehlivost MySQL klesala.

Chápu, že „Sun“ je označen za dobrý a tak se bráníte kritice Sunu, ale ze všech tří vlastníků MySQL za jeho éry měla MySQL nejvíce chyb a nejnižší spolehlivost. Kdyby měl Sun (pokud by existoval) MySQL o rok až dva déle, musela by se za ní hledat náhrada, protože by neudržela spolehlivě ani data.

Na druhé straně je pravdou, že se nevědělo a neví se, co s MySQL udělá Oracle. Vlastně se to spíše tuší – Oracle to bude chtít zavřít a dříve nebo později zavře. A bude dělat kdejaké schválnosti.

Na druhé straně Oracle dal MySQL dopořádku, opravil dlouho neopravované chyby, dotáhl polorozdělané věci po Sunu.

Stojím si zkrátka do posledního puntíku za vším co jsem napsal. Sun nevedl MySQL dobře, což by se za rok dva plně projevilo na plné kule. Oracle vede MySQL po technické stránce vynikajícně, ale zase bude bránit volnému využití MySQL. Prostě je to jako sednou si holým zadkem na rozpálená kamna – jedno jestli u Sunu nebo Oracle – jen pokaždé si ten zadek spálíte jiným způsobem.

[okbob]

Právě, že to máte posunuté - v MySQL A.B se po vydání 5.0 soustředili na vydání 6.0 s Falconem. A tři roky se nic zvláštního nedělo. Pak bomba - MySQL bylo koupeno Sunem - přičemž Sun zásadně změnil vývojový model - 6.0 byla odpískána - připravila se 5.5. Oracle fakticky udělal zatím jediné - upgrade na poslední verzi InnoDB - jinak velká část fíčur z 5.6 byla rozdělána ještě v MySQL A.B, a finalizována v Sunu - případně jejich vývojáři dnes sedí v Perconě.

Jinak ač mám pár kamarádů, kolegů ze Sunu - jako Postgresista nemám důvod obhajovat Sun více než je nutné - poměrně intenzivně deklarovali podporu PostgreSQL, kterou po koupi MySQL rychle zařízli :).

Ač se to nezdá pro Oracle přirozené - MySQL kompatibilní konkurence - PerconaDB, MariaDB, Drizzle by si výskli radostí, kdyby Oracle MySQL zavřela. Takže jak znám Oracle - tipoval bych, že MySQL nezavřou - ne, že by to dělali z nadšení pro Open Source, ale nebudou konkurenci otevírat vrátka - a Oracle si může dovolit neřešit finance u jednoho produktu.

[Miloslav Ponkrác]

Já pořád nechápu jednu věc. Pochopil jsem, že se snažíte napsat, že nemám pravdu, ale přitom tvrdíte to samé co jsem napsal.

Znovu, až budu chtít psát vědeckou práci, nebo třistrstránkovou knížku se všemi detaily, tak nebudu plýtvat písmenky v diskusi, ale napíšu knížku a nechám si jí zaplatit.

V diskusi píši stručně.

Základní fakta jsou stejná, pro jistotu speciálně pro Vás, nechápavého to napíši:

1) !!!!!!!!!! InnoDb vlastnil Oracle od roku 2005 !!!!!!!!!!!!!!!!

2) Od této doby se vlastník(ci) snažili nahradit InnoDb Falconem.

3) Když Oracle získal MySQL, tak zaříznul Falcon, protože InnoDb vlastnil a neměl proč ho narazovat.

Čemu na tom nerozumíte, že se snažíte pořád psát, že nemám pravdu a přitom netvrdíte nic výrazně jiného, než jsem napsal? Můžete mi to proboha mě, nechápavému, vysvětlit?

---

PerconaDB ani Drizzle rozhodně není MySQL kompatibilní konkurence. PerconaDB má kompatibilní s MySQL pouze komunikaci mezi klientem a serverem, samotné SQL a databáze s MySQL kompatibilní není. Nehledě na to, že u PerconyDB bych zavření a komerční využívání ála Oracle čekal taky.

Drizzle je zase vykastrovaný klon MySQL, který toho umí asi dvacetinu oproti MySQL. Kromě toho je pouze POSIX only, takže nemá ani Windows verzi, ani verzi pro některé komerční unixy. Drizzle není kompatibilní vůbec v ničem, jediná příbuznost s MySQL je, že někde na začátku si autoři prohlédli zdrojáky MySQL a tím to končí. Ve skutečnosti má Drizzle jinou architekturu, jiné jádro, jiný komunikační protokol server-klient, je napsán v jiném programovacím jazyce, než MySQL, nemá dvě třetiny datových typů co má MySQL, nemá procedury, nemá triggery, nemá views, a tak by se dalo pokračovat ještě hodně dlouho co nemá. Dokonce neumí pracovat ani s lokálním časem, všechno nouzově ukládá v UTC. Dělat z tohodle náhradu MySQL je opravdu těžký omyl.

Jediná rozumná náhrada je MariaDB, jenomže ta pouze kopíruje MySQL. Pokud Oracle vyhodí něco z free verze a přesune to do komerční verze, MariaDB také tuto featuru smaže. Jakmile Oracle MySQL zavře, je MariaDB berzradná. Nahledě na to, že není příli morální nejdřív MySQL prodat, vyinkasovat mnoho melounů v dolarech a pak řvát, že si s tím kupec dělá co se mu zlíbí a na protest založit MariaDB.

[okbob]

To, co se tu snažím sdělit je, že FALCON byl zaříznut Sunem - nikoliv Oraclem

Co se týče Percony, tak to se pletete - viz http://www.percona.com/software/percona-xtradb případně zápisy na http://planet.mysql.com/ např. http://openlife.cc/blogs/2012/august/state-mysql-forks-conclusions - kde se o Perconě píše jako o db, kde aplikují Oracle MySQL patche - tudíž to zatím je kompatibilní i na úrovni zdrojáků - resp. lze na to aplikovat patche.

Drizzle je psán v C++, MySQL je psáno v C++ - pro hromadu uživatelů MySQL, kterým stačí MySQL 4.0 je Drizzle to pravé a na ně cílí - a "zbytečnosti" jsou osekané - např. podpora jiných kódování než UTF8 - podpora win a pod - kdo má win na serveru?

Ohledně Marie - jelikož si píší vlastní engine - tak se rozhodně nedá říci, že je to jen free fork Oracle. Je jasné, že se Vám Monty nelíbí, ale to, co tu píšete prostě jsou jen polopravdy.

[Miloslav Ponkrác]

„To, co se tu snažím sdělit je, že FALCON byl zaříznut Sunem - nikoliv Oraclem“

To se ale pletete, Falcon zařízl Oracle. Viz

http://www.databasejournal.com/features/mysql/article.php/3876206/Oracle-Commits-to-MySQL-with-InnoDB.htm

---

„Co se týče Percony, tak to se pletete …“

U Percony hlavně není příliš jistota, že nebude dělat stejné obstrukce jako Oracle.

---

„Drizzle je psán v C++, MySQL je psáno v C++ - pro hromadu uživatelů MySQL, kterým stačí MySQL 4.0 je Drizzle to pravé a na ně cílí - a "zbytečnosti" jsou osekané - např. podpora jiných kódování než UTF8 - podpora win a pod - kdo má win na serveru?“

Drizzle cílí na cloudy. Už si udělalo místo pro možnost NoSQL v komunikačním protokolu.

Drizzle se natají tím, že optimalizuje na tisíce paralelně připojených uživatelů a je mu fuk, jak rychle a dobře bude databáze chodit s jedním nebo se dvěma konekcemi. Tedy pokud něco může urychlit o pár procent vykonávání paralelních tisíci konekcí za cenu, že databáze s jednou konekcí se mnohonásobně zpomalí, Drizzle to udělá. (Máte to psáno hned na prvních stránkách dokumentace o Drizzle.)

Drizzle je něco, co je osekané poněkud nad míru. Jejich cíle jsem popsal výše.

Win na serveru má hodně lidí a hlavně MySQL není používána jen jako serverová databáze ale i jako databáze pro aplikace.

A to co říkám pořád: Databáze bez verze na Windows se masově a dlouhodbě neuchytí. Historie nikdy nic jiného nepotvrdila.

Promiňte, ale Drizzle je to poslední co by mělo být náhradou za MySQL. Cokoli jiného jen ne Drizzle. Pro účely cloudu nebo masivně paralelního využívání to může být dobré.

[Miloslav Ponkrác]

„Ohledně Marie - jelikož si píší vlastní engine - tak se rozhodně nedá říci, že je to jen free fork Oracle. Je jasné, že se Vám Monty nelíbí, ale to, co tu píšete prostě jsou jen polopravdy.“

MariaDB si musí vybrat, buď bude přímou náhradou za MySQL, a nebo se vydá vlastní cestou a pak nebude.

To co píši je podloženo pečlivým studiem dokumentace a diskuse na jejich webu.

Protože už nějakou dobu tuším, že po roce 2015 Oracle udělá cosi, co zavaří free uživatelům MySQL, tak zjišťuji informace. Prošel jsem detailně MariaDB, Drizzle, i PerconuDB, stejně jako další projekty, které jsem neuvedl. A zjistil jsem, že je to docela zoufalé.

Mě by bohatě stačila vhodná relační databáze s SQL, která by fungovala spolehlivě multiplatformně, byla by klidně zcela nekompatibilní s MySQL a byl bych spokojen. Nicméně vše co jsem prošel není úplně to pravé ořechové.

Jinak já nic proti Montymu nemám. Jenom jsem upozornil, že jeho lkaní kolem MySQL není zcela morální a že je tohodle sám do značné míry spoluviníkem.

Ale MariaDB neustále přidává featury, pak je škrtá,l pak zase přidá, pak je pro jistotu nechá jen pro ty co si to zapnou při kompilaci, pak ho zruší úplně. Pak přidá něco jiného a takový kolotoč pořád do blba.

Dokud je MariaDB přímou náhradou za MySQL a snaží se poskytnout stejné featury jako MySQL, dá se to snést. Ale předsta, že by se MariaDB stala pokračovatelem MySQL a nebyla schopná ani udržet featury, které přidá do stable verze – to se mi ekluje jako potenciálnímu uživateli.

[Miloslav Ponkrác]

Mimochodem, MariaDb je vysoce „morální“ příběh.

Widenius, který prodal svou společnost MySQL A.B. Sunu a utržil za ní 16,6 miliónů dolarů (tedy plus mínus 300 miliónů Kč v dnešním kurzu) následně zakládá pod heslem „zachraňte MySQL„ MariaDb.

Widenius, kdyby nebyl pokrytec, nemusel MySQL prodávat. A když už ho prodal, tak by se měl starat o osud MySQL před prodejem. Třeba přidat doložky, že MySQL musí zůstat open source. Jenže to by vydělal méně penízků, a tak je lépe penázky inkasovat v plné výši a pak se strachovat o něco čeho byl vlastním strůjcem.

[okbob]

Trochu nudných dat

• 2005 - Oracle kupuje InnoDB
• duben 2007 - ohlášena 6.0 s Falconem
• leden 2008 - Sun kupuje MySQL AB
• červen 2008 - Jim Starkey opouští Sun
• duben 2009 - Release 5.4 "neviditelna verze" - zaklad PerconaDB, MariaDB, MySQL 5.5 viz zásadní funkce jako např. optimalizace poddotazů
• duben 2009 - Oracle kupuje SUN
• prosinec 2009 Oracle release 5.5 - přebandlovaná 5.4
• prosinec 2010 Oracle GA 5.5

Sun vlastnil MySQL cca 14 měsíců - když vezmete zmatky při slučování firem a před převzetím, tak efektivně něco kolem jednoho roku.

[Miloslav Ponkrác]

Pochopil jsem, napsal jste tuny textu a stránky písmenek nesouhlasu jenom proto, že jsem si dovolil nezdůraznit, že Falcon byl ohlášen už přes Sunem.

Nicméně já celou dobu píši o tom, proč byl Falcon vůbec zamýšlen a proč byl odpískán.

Ohlášení Falconu je jenom ohlášení plánu. Skutečný release byl na Sunu, a to bylo pro něj těžké období, když jednak zdrhnul hlavní autor.

Kdyby Sun vlastnil efektivně MySQL ještě rok dva, tak MySQL zničí výrazně rychleji, efektivněji a destruktivněji, než to dělá dnes Oracle.

[Martin Mareš]

Hlavní impuls přišel od PHP, které obešlo jeho licenci k libmysql tím, že si napsalo vlastní implementaci této knihovny pod názvem mysqlnd.

Rozhraním DB by měl být síťový protokol, ne nějaká knihovna. Knihovnu nechť si klidně každý pro svůj programovací jazyk napíše sám.

[Miloslav Ponkrác]

Rozhraní db by mělo být API. Tak tomu bylo, je a bude u většiny databází i jiných projektů.

Není důvod aby tomu bylo jinak.

Každý projekt udržuje API, zatímco na úrovni implementace se snaží dělat optimalizace.

Nehledě k tomu, že databáze nemusí komunikovat po síti, což je i jeden z režimů komunikace mezi klientem a serverem u MySQL. Lze komunikovat přes soket, nebo u embedded MySQL se dokonce žádná meziprocesorová komunikace nekoná vůbec – protože by to byla blbost na entou a kravina jako vrata.

[Martin Mareš]

Chtít po vývojářích DB, aby poskytovali API pro všechny kombinace OS + architektura + programovací jazyk, na kterých by lidé chtěli k DB přístupovat, je ptákovina. Ve světě DB běžná ptákovina, ale to jí na ptákovinovitosti neubírá.

Prakticky kdekoliv jinde, kde se používá server, k němuž se připojují klienti po síti (ať už mezi počítači nebo interní síti v rámci jednoho počítače, jako je UNIX-domain socket), je standardizován protokol. Tak tomu je od nepaměti a tento model se velice osvědčuje. Nevidím, že by SQL DB byla v čemkoliv speciální, aby bylo výhodnější místo protokolu standardizovat API.

Dokonce jsem přesvědčen, že takový protokol by měl být přímo součástí standardu SQL a být společný pro všechny DB servery.

[Miloslav Ponkrác]

Možná jste to ještě nezjistil, ale pokud databázoví vývojáři dávají API v jazyce C, pak je jednoduché toto API použít v každém myslitelném programovacím jazyce.

Tudíž není třeba řešit programovací jazyky. Každý dnešní programovací jazyk si umí přebrat nějak API pro jazyk C.

Stejně tak nekomuntuji Vaši lež o tom, že kdekoli se připojují klienti po síti, že byl standardizován protokol. To zřejmě žijete na Marsu a ne na Zemi.

Ba právě naopak, je standardnější a častější, že je použito API v C stylu a komunikace se bere jako černá skříňka. Tak je tomu od nepaměti a tento model se velice osvědčuje.

Znovu, asi jste to přehlédl, SQL jazyk ani relační databáze nemusí vůbec komunikovat po síti nebo mezi procesy. Třeba takové embedded databáze nekomunikují vůbec, prostě jednoduše rovnou voláte API funkce serveru, které jsou ve stejném adresovém prostoru jako je klient. Není zde třeba žádné komunikace.

Jakýmkoli zafixováním síťové komunikace by se dosáhlo pouze toho, že by se nemohly zlepšovat ani optimalizovat po stránce této komunikace.

Většina databázových strojů, počínaje MySQL, přes další a další – má komunikační protokol standardizovaný, ovšem s výhradou, že může být kdykoli změněn. Jediné co se zaručuje je API. Klidně si můžete napsat vlastní komunikaci klient-server pro MySQL. PHP to tak udělalo.

[Martin Mareš]

Možná jste to ještě nezjistil, ale pokud databázoví vývojáři dávají API v jazyce C, pak je jednoduché toto API použít v každém myslitelném programovacím jazyce.

Což je často zbytečná komplikace, protože mezikus mezi C a daným jazykem je často složitější než přímá implementace vesměs triviálního protokolu.

Stejně tak nekomuntuji Vaši lež o tom, že kdekoli se připojují klienti po síti, že byl standardizován protokol. To zřejmě žijete na Marsu a ne na Zemi.

Ehm, neřekl bych, že zrovna vy jste v těchto končinách považován za osobu s dost velkým rozhledem na to, aby jí kdokoliv věřil takováhle tvrzení Takže byste je měl buďto doložit nebo odvolat. Astrologické argumenty neberu

Jakýmkoli zafixováním síťové komunikace by se dosáhlo pouze toho, že by se nemohly zlepšovat ani optimalizovat po stránce této komunikace.

Že jsem tak smělý, jaká optimalizace komunikace byla na tomto poli za posledních 20 let zavedena? Posílání dotazů a odpovědí na ně je natolik triviální záležitost, že není potřeba desítek roků vývoje na to, aby se našlo slušné řešení.

Většina databázových strojů, počínaje MySQL, přes další a další – má komunikační protokol standardizovaný,

Zrovna u MySQL je zveřejněn stručný popis protokolu, rozhodně ne pořádná specifikace.

Jinak o embedded databázích tu nikdo kromě vás nemluví, ty mohou mít interface jakýkoliv, dokonce to často ani není SQL, ale primitivnější operace.

[Miloslav Ponkrác]

„Což je často zbytečná komplikace, protože mezikus mezi C a daným jazykem je často složitější než přímá implementace vesměs triviálního protokolu.“

Každá standardizace je kompikací.

---

„Ehm, neřekl bych, že zrovna vy jste v těchto končinách považován za osobu s dost velkým rozhledem na to, aby jí kdokoliv věřil takováhle tvrzení Takže byste je měl buďto doložit nebo odvolat. Astrologické argumenty neberu“

To jak mě vidíte, je pouze Váš problém. Máte plné právo si o mě myslet cokoli, jenom máte problém, že mě je to fuk a nebudu na to brát zřetel.

Stejně tak mi je fuk, za co jsem považován. Nechápu, že si pořád spousta lidí myslí, že mě to nějak eminentně zajímá. Je mi to fuk, dělá-li Vám radost snažit se mě sestřelit osobním útokem, dělejte to. Pokud to pomůže Vaší psychice, mě to neuškodí, klidně pište.

---

„Že jsem tak smělý, jaká optimalizace komunikace byla na tomto poli za posledních 20 let zavedena? Posílání dotazů a odpovědí na ně je natolik triviální záležitost, že není potřeba desítek roků vývoje na to, aby se našlo slušné řešení.“

To jistě není. Ale komunikační protokol musí být schopen pojmout třeba případné budoucí extenze a featury databázového stroje. Tedy být schopen budoucí úpravy.

Není třeba standardizovat víc, než je třeba. Bohatě stačí standardní API.

---

„Zrovna u MySQL je zveřejněn stručný popis protokolu, rozhodně ne pořádná specifikace.“

A celý zdrojový kód knihovny pro komunikaci.

---

„Jinak o embedded databázích tu nikdo kromě vás nemluví, ty mohou mít interface jakýkoliv, dokonce to často ani není SQL, ale primitivnější operace.“

Vy jste mluvil o tom, že chcete standardizovat komunikační protokol jako součást SQL. Tak jsem jenom připomněl, že existují i databáze s SQL, které komunikovat meziprocesně nepotřebují, třeba embedded.

Protože na rozdíl od Vás jsou strůjci SQL protokolu praktičtí a zkušení lidé, tak je ani nenapadla taková hovadina jako standardizovat komunikační protokol jako součást SQL standardu.

[Martin Mareš]

dělá-li Vám radost snažit se mě sestřelit osobním útokem,

Ne, pouze konstantuji, že zde nepožíváte tak velkou autoritu, aby dávalo smysl brát vážně vaše obecná tvrzení bez náznaku důkazu.

Jinými slovy neodmítám tvrzení proto, že jste ho řekl vy, ale proto, že je nepodložené. Pouze dodávám, že kdyby ho řekl někdo, kdo má lepší reputaci, ležela by laťka pro dostatečnost podložení trochu jinde.

A celý zdrojový kód knihovny pro komunikaci.

To není náhrada specifikace protokolu.

Vy jste mluvil o tom, že chcete standardizovat komunikační protokol jako součást SQL. Tak jsem jenom připomněl, že existují i databáze s SQL, které komunikovat meziprocesně nepotřebují, třeba embedded.

Toto se ve standardech obvykle řeší tak, že standard doporučí protokol, který se má použít v případě, že se se serverem komunikuje po síti.

Jasná paralela jsou třeba e-mailové systémy. Existuje standardní formát zpráv a protokol (SMTP), který se používá pro přenos mailů po síti. Jak si který systém posílá maily uvnitř jednoho počítače, standard neřeší.

Protože na rozdíl od Vás jsou strůjci SQL protokolu praktičtí a zkušení lidé, tak je ani nenapadla taková hovadina jako standardizovat komunikační protokol jako součást SQL standardu.

Já to vidím spíš tak, že strůjci SQL stále žijí v 80. letech a ignorují 30 let vývoje a standarizace síťových protokolů a s tím spojených výhod.

[okbob]

ANSI SQL skoro výhradně neřeší implementační záležitosti a mezi to patří i komunikace mezi klientem a serverem.

Ne, že by to asi někoho nenapadlo, ale standard musí odsouhlasit velcí hráči - Oracle, IBM, Microsoft - a ti nemají nejmenší motivaci snížit vendor lock.

[Martin Mareš]

Což je často zbytečná komplikace, protože mezikus mezi C a daným jazykem je často složitější než přímá implementace vesměs triviálního protokolu.

Mimochodem, absurdnost celé situace vynikne v okamžiku, kdy jeden program chce umět využívat různé DB servery. Tehdy se musí vyrovnat s houštinou knihoven s různým API, místo aby používal jednu knihovnu, která se jednotným protokolem bude bavit se všemi DB.

[Miloslav Ponkrác]

Jo jo, svět je nespravedlivý a hnusný.

Ale řekl bych, že bych se raději prodíral houštinou několika knihoven, které mi nabídnou API, než řešil low level detaily síťové komunikace.

Na Windows existuje ODBC nebo OLE DB, a to funguje velmi pěkně a na jednotném API. Můžete bez problému napsat program připojující se k mnoha databázím aniž byste se houštinou knihoven prodíral. A aniž byste znal detaily síťové komunikace.

Něco podobného funguje v rámci JAVA a JDBC.

Atd.

[Martin Mareš]

Ale řekl bych, že bych se raději prodíral houštinou několika knihoven, které mi nabídnou API, než řešil low level detaily síťové komunikace.

To po vás také nikdo nechce. Cílový stav by měl být společný protokol a pro každý jazyk standardní knihovna, která tímto protokolem hovoří a poskytuje API přirozené pro daný jazyk.

Netřeba stavět hromady meta-abstrakcí typu ODBC. (Navíc meta-abstrakce skřípou tam, kde různá API skrytá pod nimi mají různou sémantiku. A že ve světě databázových API takových sémantických pastí je spousta...)