A Sun megvásárolja a MySQL-t

MySQL, MariaDB

A Sun Microsystems bejelentette, hogy megegyezés született a MySQL AB megvásárlásáról. A körülbelül 1 milliárd USD értékű ügylet eredményeként a 400 alkamazottat számláló MySQL AB várhatóan beolvad a Sun Microsystems-be, a vezérigazgató, Marten Mickos pedig helyet kap a Sun felső vezetésében. Bővebben itt.

Frissítés: Kaj Arnö, a MySQL alelnökének blogjában részletesen a dologról, arról, hogy mit jelent ez a MySQL közösség számára, stb. A blogbejegyzés itt.

--

A Sun a mail napon bejelentette felvásárlási szándékát a MySQL-re. Bővebb infó itt.

--

Megvásárolja a legnépszerűbb nyílt forrású adatbázist, a MySQL-t fejlesztő és forgalmazó MySQL AB vállalatot a Sun Microsystems, amely a kerek 1 milliárd dolláros vételárat 800 millió dollár készpénzben és 200 millió dollár saját részvényben egyenlíti ki. Az akvizícióval a Sun belépett a közel 18 milliárd dolláros adatbázispiacra, amelyet az Oracle és az IBM ural.

( PMC | 2008. 01. 16., sze – 15:46 )

Legalább lesz elég pénz a MySQL fejlesztésére is...

( szdl | 2008. 01. 16., sze – 16:52 )

Ez szép! Reméljük nyer vele mindenki és nem veszít..

( molgab v | 2008. 01. 16., sze – 16:58 )

Az ilyen felvásrálásoktól mindig félek... de szerencsére még ott a postgree ha netán valami balul sülne el...

Nem vagyok egy kozgazdasz, ezert valaki elmagyarazhatna, hogy hogy lesz ebbol uzlet a Sun-nak? A MySql free, a 400 dolgozot fizetni kell, persze egy nagy reszuket atszervezik, vagy kirugjak, mi ebben a business?
Egyaltalan nehezen tudom elkepzelni, hogy mibol el a Sun? Egyre-masra jonnek a hirek, hogy leepit, atszervez, megbuknak a processzorai, mibol van bevetele? A java oktatas ennyit hoz? Igaz nem olcsok a tanfolyamok es a vizsgak is eleg dragak, de hat ebbol nem lehet megelni. Vagy megis?

akkor már csak 1 kérdés van és minden világos :D
csak hogy tiszta legyen minden

mi a helyzet az ingyenes tárhelyekkel... (atw,extra,uw stb...)
értelmezésem szrint mindenki számára ingyenes, de amint készítek egy progit és felnyomom pl. atw-re netán SMS formájában értékesítem a "szolgáltatást", meg kell vennem a kereskedelmi licenszet :D

Mivel az opensource MySQL is GPL, ezert ugyanazokkal a feltetelekkel hasznalhatod, mint a PHP-t, apache-ot, stb...
Tehat ha irsz egy programot vmely interpretalt nyelven (pl. PHP), akkor hasznalhatod a GPL-es MySQL-t akar uzleti celra is.
DE ha mondjuk C-ben irsz egy progit, amiben hasznalod a mysql.h-t, akkor ket lehetoseged van:
- kiadod a forrasod GPL-kent
- megveszed a keredkedelmi verziot, igy maradhat a kodod zart

Jol latom?

Nekem egeszen veletlenul van egy zlib/png (ez is oss slicence) progim, ami hasznalhatja a libmysqlclient.so-t. Megkerdeztem a mysql-t, hogy ez igy koser-e? Nem valaszoltak, en meg rantottam egyet a vallamon, es hallgatas = beleegyezes alapon, ezt "+OK\r\n" uzenetnek vettem.

ASK Me No Questions, I'll Tell You No Lies

Magyarországon is jó néhányan megvették a MySQL Enterprise-t, ezután a Sun-tól fogják megvenni. Sőt, ha a Sun nyújt globális supportot, akkor többen fogják megvenni.

Ezen kívül: _nagyon sokan_ használnak MySQL-t, ez egy remek alkalom egy kis imázs növelésre, ha a terméket a megfelelő mederben fejlesztik tovább (ez a terv). A MySQL szónak súlya van, ahogy az OpenOffice-nak is (ZFS, OpenSolaris, NetBeans, kinek mi..), ha OSS commitment-ről van szó.

A vételi ár a 400 alkalmazotthoz, és a cég bevételéhez képest nem kevés, a mostani web2-felvásárlási lázhoz képest viszont kifejezetten nem sok, szerintem jó vásárt csináltak.

Kevesen vannak vele tisztában, de a Sun eddig is vállalt supportot open source rendszerekre a hagyományos support szerződésein keresztül. A Solaris mellett szállított vagy tőlük letölthető termékekre (gyk. /usr/sfw) eddig is volt valamiféle support, ami sajnos abban az esetben, ha az alkalmazásban volt a konkrét hiba, kimerült abban, hogy reportolták a fejlesztők felé a bugot. Elképzelhető, hogy nagyobb vásárlók esetén pl. site-wide agreement-el viszont eddig is a Sun támogatta az ügyfél MySQL installációit (egyebek mellett). A bejelentésben említett cégek között máris látok olyat, ahol erről lehet szó. Ekkor viszont elképzelhető, hogy minden más faktort figyelmen kívül hagyva már pusztán azzal megtérül az akvizíció, hogy:

a) a supportot eddig is a Sun csinálta, de nem volt ráhatásuk a mysql fejlesztésére. Most házon belül tudják megvalósítani az igényeket, hibajavításokat, olcsóbb lesz nekik a support nyújtása.
b) ahol eddig a MySQL AB-nek fizettek a supportért, ott most a Sun-nak fognak.

(a) eset, vannak olyan problémák a MySQL-ben, amik nagyüzemi felhasználásnál jelentkeznek, ha ezeket kijavítják (évek óta húzódik) már örülök.

Én frissen úgy hallottam, hogy nagyon komoly (500 fő) programozói erőforrást állítanának rá a MySQL-re azonnal (még az akvizíció lezárása előtt), persze ez nem megerősített, csak szóbeszéd. Valamikor a MySQL AB is a Solarist ajánlotta, mint elsődleges platform, ha nagyobb telepítésről van szó, ha ezt visszaszerzik, már annak nagy jelentősége van, de szerintem ennél többről van szó.

Hogy miből él a Sun? Azt nem tudom, én egy Sun partner vagyok, csak azt tudom, mi miből élünk, és azt, hogy ez az akvizíció konkrétan üzletet és bevételt fog hozni.

( maat | 2008. 01. 16., sze – 17:03 )

Csak mert nincs elég felsővezető a Sunnál.

( styg v | 2008. 01. 16., sze – 19:37 )

Asszem a PostgreSQL felkötheti a gatyáját - és ez a (GPL) piacnak csak jót tesz...

MySQL-bol meg mindig csak az innodb tud tranzakciot, idegen kulcsot, sor szintu lockolas.
Az meg ugye nem olyan gyors, mint a default Myisam motor, amivel mindig tesztelik, hogy milyen gyors, amik emellett meg nagyon serulekenyek is.
Sajat tapasztalat alapjan egy bizonyos rekordszam folott exponencialisan novekszik a tablakban a kereses(sima select elsodleges kulcs alapjan 10 milla rekordra mondjuk x ido, 20 millara mar joval tobb, mint 2x)
Illetve nekem szemely szerint jobban bejon a postgresql-el oracle-hoz hasonlo plpgsql megvalositasa (ami helyett hasznalhatok C-t, vagy Java-t, vagy PHP-t, vagy barmit), mint a MySQL sajatja.
Mysql-ben az egyetlen jo dolog, az az Innodb.

Tyrael

> Mysql-ben az egyetlen jo dolog, az az Innodb.

A Mysql-t legtobb helyen webes alkalmazas mogott hasznaljak. Namost a legtobb phpmatyizo a "S ELECT * FROM table" kifejezesen kivul mast nem tud hasznalni, szamukra olyan mindegy az 500 soros tablaknal, hogy innodb van-e alattuk vagy eppen myisam :) Viszont megvan az az elonye, hogy joval egyszerubb uzemeltetni mint egy postgresql-t, es elbarmolt lekerdezesek eseten is aranylag jo teljesitmenyre kepes.

Ha egyetlen jo dolog, akkor en sokkal inkabb a replikaciot hoznam fel a postgresql-el szemben, mert komolyabb alkalmazas eseten erre sokszor szukseg van.

A "phpprogramozó" leginkább onnan ismerhető fel, hogy a MySQL rászoktatta arra, hogy a forráskódba tegye az SQL queryket, amellyel aztán jönnek az SQL injection hibák és a többi.

Azért az NDB-nek is van némi értéke, bár némelyik, fent említett "programozó" által készített programmal (legalábbis ez a tapasztalatom eddig) használhatatlanul lassú.

"a forráskódba tegye az SQL queryket, amellyel aztán jönnek az SQL injection hibák és a többi."

Ez FUD? Csak halkan mondom, hogy egyikbol nem kovetkezik a masik (vagy ha megis osszejon, az nem mysql specifikus feature). Meg hiaba torom a fejem, de nem jut eszembe jobb (se egyszerubb) mondjuk egy select eseteben (barmilyen db-rol is legyen szo), hogy:

$stmt = "s" . "elect x from ....";
sql_exec($stmt);
...

ASK Me No Questions, I'll Tell You No Lies

> SQL injection hibák és a többi.
Igen, a spagettikod jelentosen elosegiti ilyen hibak elofordulasat, de azert ez nem csak az omlesztett kod/html/query es a szokasos php mentalitas kovetkezmenye, hanem a tajekozatlansage es a figyelmetlesege inkabb. Illetve a bekapcsolt magic_quotes_gpc csodae ami raszoktatja az embereket arra, hogy ne foglalkozzanak az inputtal. (aztan persze neznek nagyokat amikor megis atcsuszik valami :> )
A bejovo inputot ugyis a kodban fogod szurni, tokmindegy hol vannak a queryk, mert nem az fog megvedeni az ilyen jellegu problemakkal szemben, hogy nem a koddal egyutt van.

Az NDB-t ne is emlegesd :D Sima mysql master-slave replikaciorol (ami kivaloan mukodott) probalkoztunk atterni ra, de hatalmasakat szivtunk normalis querykkel is. Nem tudom javult-e azota a helyzet, de jo ideig latni sem akarom inkabb :)
Viszont a postgresql-be mar az is nagyon jol jonne, ha legalabb egy mysql szintu master-slave felallast tudna alapbol nyujtani.

nehogy már a nyúl vigye a puskát. nem a mysql szoktatta őket rá, elkövetnék (elkövetik) bármivel, csak éppen "LAMP! LAMP! LAMP!" ezt választják. a gány, fos munkára sem a php szoktatja rá őket, hanem úgy alakul. (gondolom)
Nézz meg magyar fejlesztésű komolyabb (értsd: nem a legkisebb 1 useres delphis) ügyviteli szoftvereket találomra, még borzalmasabb, pedig az se mysql, se php, inkább oracle, meg vizsual mit tudom én mi.

Arra céloztam, hogy amikor indult ez az egész mizéria a MySQL-lel (aka. "webprogramozás"), esélyük sem volt rá, hogy az adatbázis felé API-kat építsenek (pld. tárolt eljárásokon keresztül kommunikáljanak vele, ne pedig SQL-lel a programból), így ehhez szoktak, ha egy kicsit is fejlettebbek voltak szellemileg, akkor sem tudták volna ez megoldani. Legalábbis MySQL-lel nem. :)

manapsag telepitettem oracle-t, mert kellett. csak a kliens (rendes, nem instant) 500+ Mega volt. Maga az adatbazis 2G+ (es hozzateszem, hogy ez csak a 9i, nem pedig a legujabb)
ugyan ez pg-ben a kliens talan ha 4M+ mig a szerver resze 10-20M+ ehhez képest, az oracle ha nem tud többet akkor egy kalap szar. amennyi kód van abban tudnia KELL/ILLIK/MUSZALY. A pg-ről meg annyit, hogy szerintem is a legjobb a méretéhez és tudásához képest és méltatlanul kevesen ismerik. Nem beszélve arról, hogy sokkal közelebb van az SQL szabványokhoz mint a többiek. Egyébként érdekelne, hogy tud -e a mysql bármely verziója PLSQL-t futtatni, függvényeket, procedure-okat, pg-szerű rule-okat lehet vele csinálni? (őszintén érdekel, mert szükségem lenne rá)

Ugye "muszáj"-ra gondoltál?

Amúgy nagyon egyszerű a helyzet: a [Pg|My]SQL nem egy kategória az Oracle-el, elég eltérőek a felhasználási területek. Persze 1-1 kivétel van, de amellett tekintsünk el. Ha _biztosan_ adatvesztés mentes, nagyon sok felhasználós adatbázis kell, akkor valószínüleg Oracle[/IBM] jobb választás, viszont minek használjon olyat egy sima kkv weboldala, ahol a napi mentés majd' mindig elég. Ágyúval nem érdemes lőni a verébre, de ez fordítva is igaz: a mammut se hal ki egy légpuskától.

Pg amúgy szerintem is jobb My-nál, habár nagyon mélyen nem másztam bele a témába, egyszerűen ez áll kézre.

Nincs értelme egymás hibáit javítani, mert ez itt nem egy nyelvészeti oldal, azonkívül udvariatlan. De összekeverni az

elmegy valami mellett,
és eltekint valamitől

vonzatát imho nagyobb nyelvi hiba, mint a j/ly tévesztés, aminek egyébként túl sokan túl nagy jelentőséget tulajdonítanak.

--
CCC3

Biztos van, akinek megfelel amit a MySQL tud, ezek szerint ti ilyenek vagytok.

Nem értek ezekhez (sem), a napi 15k tranzakció soknak számít?
Azért kérdezem, mert itt napi 10-20 millió (utóbbi ritkább, de elbírja a gép) megy egy DB-be, pár kisebb (legfeljebb párszor (<10) annyi bájtos, mint amennyi tranzakciód van naponta) PL/SQL (ahhoz sem értek, de próbáltam egy scriptet portolni még 5-ös MySQL-be és igen hamar rájöttem, hogy nem csereszabatos a kettő) scripten keresztül.

Szóval most kicsit elbizonytalanodtam, hogy a 15k e-penis lengetés, az igen kis forgalomra való célzás, vagy csak elírás volt-e.

az hogy jott ki?
50 000 000 000 / 3600 az ~13 888 889
2 gepre leosztva mar csak ~6 944 444 tranzakcio masodpercenkent.
azt irta a srac, hogy AMD64es procik, ergo valszeg ilyen 1,6GHz megvan.
1,6 GHz az 1 600 000 000 orajelciklus, ha jol szamolok.
jo persze, ezt nem csak a mysql hasznalja, meg satobbi, de nagysagrendileg akkor sem latom, hogy hogy johet ki a tobb tiz/szaz tranzakcio / cycle.

Tyrael

Kb. egy másfél éve próbáltam áttérni pgsql-ről mysql-re. Pont a gyorsaság miatt.
Azután rá kellett jönnöm, hogy a MySQL 5x nem csak lassabb már több felhasználós környezetben mint a Postgres, hanem a tárolt eljárások stb. szinten is le van jelentősen maradva. (1 lekérdezésre gyosabb volt, de több párhuzamosra (különböző SELECT-ek) lassabb)

Az az érzésem, hogy valahogy így ment a fejlődés a kettő db-kezelőnél:
Mysql: Próbáljunk meg minél gyorsabban kiszolgálni SQL szerű dolgokat, majd idővel bekerülnek az új funkciók.
PGSQL: Csináljunk olyan adatbázist ami lehetőségeink szerint alkalmazkodik a szabványokhoz. Majd ezt optimalizáljuk.

Azt hiszem magából az új programozási technikákból is következik (XP), hogy a második a valóban helyes út.
Igaz, az elején valóban nagy nevet szerzett magának a MySQL a gyorsasággal és ez el is terjesztette. A másik az egyszerűsége: úgy hordozhatók a táblák, adatbázisok szinte mint pl. egy XLS fájl.
Apropó: Azt is mértem, hogy a MySQL 4-es sorozat ráadásul még gyorsabb is volt az én esetemben mint az 5-ös.
Mindegyik adatbáziskezelőt a neki megfelelően tuningoltam. MySQL-el csak 1 napot azzal foglalkoztam, hogy ismerkedtem/teszteltem a tuningolási lehetőségeit.

Én azért megkérdezném mely disztrón próbáltad ki a mysql-t. Mert a debian-szerűségek egyszerűen képtelenek egy normális mysql-t összepakolni, erre a saját bőrömön kellett rájöjjek. Aluloptimalizált forrás, kapcsolati korlátok, stb, stb.

Mondjuk a Gentoo-sok postgres-be nem valami jók, ezt el kell ismerjem, de abba a disztróba szerintem sebességbe a 2 felveszi a versenyt egymással. Mondom sebességbe.

SuSe volt és WinXp.
Suse alatt fordítottam mindekettőt. Igaz az oprendszert nem én fordítottam.

Bár egyszer régebben nézegettem csak a pgsql-t, hogy különböző CPU-ra, mindenféle tunning kapcsolókkal fordítva mi lesz a különbség. Ez egy dual xeon 3,02GHz-en volt.
Próbáltam i686-ra illetve följebb optimalizálni. A különbség gyakorlatilag 0 volt. Így maradtam az alap beállításoknál, az már tesztelt :-)

A WinXp alatt, csak 1 konkurens selectet néztem több bemeneti adattal. Itt a mysql volt a gyorsabb, ha nem is sokkal.

A SuSe alatt élő webszerveren futott, és itt a MySQL, ha jól emlékszem 1.5-ös loadod produkált, míg a postgres 0,5-öt a szerveren ugyanolyan forgalom mellett. Ez ráadásul annak ellenére történt, hogy a mysql-ben kénytelen voltam néhány műveletet kitolni az applikációs szerverhez, mivel adatbázisban nem tudtam megoldani.
Linux alatt kb. 20 lekérés / sec volt, az adatbázis mérete 7GByte körüli. És minden lekérést logolt is adatbázisba (1 lekérés - 1 insert).

Kedves "gdavid" kolléga, te aztán kihozod az állatot az emberből, de komolyan. Mi az, hogy "ehhez képest, az oracle ha nem tud többet akkor egy kalap szar"? Ez aztán mondat a javából! Egyszerűen nem kaptam levegőt, és vagy egy órán át kerestem az elgurult oxigénpalackomat (nyugi, megtaláltam). De bizony, hogy többet tud. Fényévekkel. Az Oracle-t a MySQL-el vagy PGSQL-el összehasonlítani kb. olyan, mint egy talicskát a LIEBHERR dömperrel. Mindkettővel lehet sittet szállítani, de mégis micsoda különbség!

Kérlek baktass már el az Oracle honlapjára és kukkantsd meg, hogy milyen lehetőségek vannak benne jó? Érdemes. Mindenesetre szotyit, tötyit, pattogatott kukoricát meg kannásbort légyszi jó előre készíts oda magadnak, mert mire a lista végére érsz alighanem mind el fog fogyni. Még akkor is, ha nem az Enterprise változatot nézed végig.

Az, hogy RAC, Grid Computing, Spatial, Data Vault, Recycle Bin, Materialized View, Database Partition, OLAP, Data Warehouse, Data Mining, Java - .NET tárolt eljárások, Database Compession, Data Guard technológia mond valamit? A többiről nem is beszélve. Sorolhatnám oldalakon keresztül, de minek. Ezt vagy érti valaki vagy nem. Ja, hogy nem ugyanaz az árkategória? Hát ez igaz. Mint, ahogy a talicska és a LIEBHERR dömper se. Ehh! Nem is értem minek ragadtam le ennél a témánál...

PutAbout

{Cogito ergo sum...}

ez mind igaz, de szerintem ő se úgy értette, hanem úgy, hogy természetesen annyiért és annyiért természetesen többet tud.

azt azért fogadjuk el, hogy van olyan építkezés, ahova a dömperrel nem lehet beállni, vagy a beállási lehetőség megteremtése tovább tartana, mint talicskával felhordani. Ekkor a melós köp egyet és azt mondja, "bloatware". Érted?

Ez igaz, csak ha felrakod otthoni PC-re és onnantól semmi mást nem tudsz használni mellette mert "kissé" meglassul a PC és a winchester folyamatosan teker. Vagy ügyes vagy és tudod tuningolni, vagy annyi RAM kell, amennyi nem is fér be a gépedbe. Kezdőknek előképzettség nélkül kifejezetten nem ajánlanám... akkor már inkább a My.
---
;-(

Aztan ott van a fejlesztoi oldal: probalj meg egy adatbazis kapcsolatot osszehozni C-ben oracle alatt (hat nem egyszeru) vagy probald meg mysql-hez (2 fuggveny). Nekem ez is szempont + a mysql adminisztracioja is sokkal de sokkal egyszerubb (szamomra).

ASK Me No Questions, I'll Tell You No Lies

fényévekkel bonyolultabb és többet tud

Szamomra ez a kulcs: bonyolultabb. En eddig kibirtam oracle nelkul, de hasznalja mindenki azt, ami az adott melohoz a legjobb. Nalam labdaba nem rughat az oracle, es imho az sql-t hasznalo user-ek 95+%-nak sem kell (a tudasa). Ahogy valaki irta talicska vs. domper.

ASK Me No Questions, I'll Tell You No Lies

A MySQL többféle adatbázosmotorral is működik, amikben csak az API közös. Nincs tehát értelme általánosságban arról beszélni, hogy _a_ MySQL jobb vagy rosszabb a Postgresnél. Nem tudom, hogy állnak a dolgok most, de volt idő, amikor a MySQL-nek három motorja volt:

1) Egy ISAM alapú, legendásan gyors, de nem tranzakciós.

2) Az InnoDB, modernebb, tranzakciós, de természetesen közel sem annyira gyors.

3) MAXDB, állítólag lett hozzá MySQL API.

Namost, amikor képbe került az InnoDB, akkor azt mondták a népek, hogy lám, a My nemcsak gyorsabb a Pg-nél, de még tranzakciós is. Ami hülység, mert vagy gyorsabb vagy tranzakciós.

Általában a felhasználók nem közlik, hogy milyen motorú MySQL-t használnak. Pl. nem tudom, hogy a HUP mit használ, vagy a Google mit használ.

Ha jól emlékszem, az InnoDB-t, a leginkább épkézláb motort (vagy a készítő céget?) megvette az Oracle. Nem tudom él-e még valahol InnoDB, de az Oraclenek az lehetett a célja, hogy ne éljen. (Megnéztem: weboldaluk mindenesetre van, még egy My logó is van rajta, ami csak tovább színezi a képet.)

--
CCC3

Most néztem utána a következőknek, mert szerintem enyhe képzavar a MaxDB-t az isam és innodb mellett említeni.
A MaxDB - MySQL kapcsolat a múlt évben "kicsit" lazult, a MySQL már nem árusítja és támogatja a MaxDB-t - ezeket újra az SAP csinálja. Valami átjárási lehetőséget fejlesztgettek köztük - az igaz (MySQL Proxy), de annak (is) vége. Más súlycsoportba esnek mint adatbáziskezelő rendszerek is.

( sartek | 2008. 01. 17., cs – 21:22 )

[nem tudom hova irjam]
ha olyan szar a mysql akkor miert hasznaljak olyan sokan?

Ez magyarázatszerűség lehet magyarázat arra, hogy miért lett népszerű és az emberek miért kezdték el használni. Azonban még nincs magyarázat arra, hogy:

- ha lelassult(?), akkor miért nem váltottak még róla
- ha keveset tud, akkor miért nem váltottak róla
- ha nem rugalmas, akkor miért használják még milliók és miért kedvence a HUP olvasóknak hosszú évek óta
- miért nem Oracle, DB2 fut a weboldalak alatt, hiszen azoknak is van ingyenesen használható verziója

Hogy miért?

- mert a weboldalak nagy része alá megfelel
- mert ahogy fentebb említették, rendkívül könnyen használható
- mert népszerű licenc alatt érhető el
- mert könnyen elsajátítható a kezelése
- mert ugyan lehet, hogy nem a leghiper-szuperebb, de teszi a dolgát
- mert millió webes alkalmazás (köztük a legnépszerűbbek) deklaráltan elsődlegesen támogatott DB-je

Így látom én.

--
trey @ gépház

Mi az, amit nem szeretek a MySQL-ben?

Zavaros dolognak tartom a kettős licenszelést. Mo-n ezt úgy értelmezik, hogy ingyenes, szerintem viszont minden profitorientált alkalmazás után fizetni kellene.

Zavaros dolog a több adatbázismotor. Van ugyan közös API, de az csak a felszín. Az API egy része az egyik motorral működik a másikkal nem, vagy másképp. Vagyis nem lehet _általában_ MySQL-re programot írni, hanem csak ilyen vagy olyan MySQL-re. A kevesebb több volna.

Elismerem, hogy nagyon megfelel webes alkalmazásokhoz. Ezeknél többnyire nincs szükség biztonságos tranzakciókra, és így érvényesül a MyISAM gyorsasága.

Külön a gyorsaságról: A gyorsaság másodrendű szempont, amíg nem nagyságrendi a különbség. Feltehető, hogy a programozók nagyjából azonos minőségben dolgoznak és ezért a gyorsaság*funkcionalitás kb. állandó. Más szóval a gyorsaság csak a funkcionalitás (biztonság) kárára növelhető.

Külön a biztonságról: Vannak adatbázisok, amik azt állítják, hogy ők 99.999999... százalékban biztonságosak (crash után konzisztens marad). Sajnos ezeket az adatokat csak a gyártók közlése támasztja alá. A gyakorlatban az ilyen 99.99.. százalékokra nem érdemes túl sok pénzt költeni, hanem valami egyszerűbb megoldásra (pl. mentésre) érdemes alapozni. Tehát az egyszerűbb megoldásoknak is van létjogosultsága.

--
CCC3

> Vagyis nem lehet _általában_ MySQL-re programot írni, hanem csak ilyen vagy olyan MySQL-re.

Kérdés, hogy milyen programra gondolsz konkrétan. Ami kliensként elérhető a mysql-ből, az természetesen mindegyik motorral működik, sztem sok ember szúrná tökön magát ha ez nem így lenne. Hogy ha bele akarsz a server forrásába nyúlni, az hogyan menne... nos, az egy nagyon érdekes kérdés. De ez szerintem nem feltétlen a leggyakoribbb felhasználási mód.

> hanem valami egyszerűbb megoldásra (pl. mentésre) érdemes alapozni.

Aki nem menti az adatbázisát bármilyen RDBMS-t is használjon, halott ember.