Dovolím si trochu zpochybnit tvrzení autora, že ke specifikovaným požadavkům má MySQL jasně nejblíž. Ve skutečnosti to zdaleka tak jasné není. Dosti vážně bych zvažoval další přirozené kandidáty, zejména Firebird nebo PostgreSQL. MySQL má navrch v posledním bodu (podpora u webhostingu) a do určité míry v předposledním (uživatelská základna) - tam má sice nejvyšší čísla, ale i uživatelská základna zmíněných databází je dostatečná na to, aby je bylo možné považovat za vyzkoušené. U PostgreSQL je pak do určité míry problémem i neexistence nativního portu pro win32 platformu. Naopak v technických hlediscích, zejména podpoře SQL a jeho standardních součástí (ne, transakce nebo procedury opravdu nejsou "něco navíc") MySQL zaostává za Firebirdem a PostgreSQL, a to dost výrazně.

Tyto technické nedostatky MySQL mají velmi nepříjemný dopad na programátorské návyky uživatelů. Projevuje se to především zlozvykem řešit na straně klienta problémy, které by správně měly být řešeny na straně databáze, zejména konzistence dat. Není to nic překvapivého, při použití MySQL to dost dobře ani jinak nejde. Tyto návyky se pak velmi špatně odstraňují. Neznamená to, že MySQL je a priori špatná, je to pouze software dosti specifický a v žádném případě ho nelze doporučit pro výuku jako typického zástupce databází.

Proto bych doporučoval příště otázku volby databáze zvážit důkladněji a upřednostnit technická kritéria před masovostí uživatelské základny. On je to svým způsobem začarovaný kruh, dokud budou odborné servery vytvářet v uživatelích dojem, že MySQL je to jediné, čím má smysl se zabývat, bude narůstat skupina uživatelů, kteří používají MySQL nikoli na základě svého kvalifikovaného rozhodnutí, ale jen proto, že ji "používají všichni, tak musí být nejlepší". A to je velká škoda, především z pohledu samotných uživatelů.

Zdravim, s tim co pisete o MySQL souhlasim. Faktem zustava, ze to je mezi uzivateli nejpouzivanejsi databaze a je k ni i nejvice odbornych knih. To same plati i o PHP... :)

Kdybychom ovšem chtěli počet uživatelů upřednostnit před technickými kritérii, museli bychom si položit otázku, proč se vlastně vůbec zabývat Linuxem... :-)

No flame please..
jen rikam, ze PHP s MySQL je nejpouzivanejsi, proto se tomu venujeme jako prvnimu. Jinak PqSQL se pripravuje, s Pavlem Cisarem jsem se bavil o Firebirdu (zatim nema cas..).

To je dobrá zpráva. Pokud by zaneprázdněnost Pavla Císaře byla dlouhodobější, nabízím se, že bych o Firebirdu mohl něco napsat.

Upřímně řečeno, i pod Linuxem jsem viděl špatně napsaný software. Pozná se tak, že místo něj lidé používají něco jiného. Nebo jinak - proč existuje pod Linux Apache nebo třebas SQUID, a proč ostatní webové servery nebo proxy používá jen málo lidí? Že by všichni stranili apačeti prostě ze setrvačnosti?

Je to prostě široký pojem. MySQL by asi nejvíc pohřbilo, kdyby všechny webhostingy začaly masivně nabízet Postgre. Což se zatím neděje; nevím proč. Uvidíme.

Především, čekal jsem malý flamewareček; už v článku je psáno, že "se můžete rozvášnit v diskusi". Takže, diskusi vítám. Z Firebirdem nemám výraznější zkušenosti; Postgre je přímo zmíněna jako zástupce "celé řady velice dobrých databází". MySQL nijak nestraním.

S MySQL pracuji dlouho, co mi na ní vadí je, že nepodporuje transsakce, uložené procedury a spouště (já vím, pětka ano...). Pak bychom se mohli bavit o výkonu, ale ono udělat srovnatelný výkonový test několika databází, aby to vyznělo solidně, to je docela dřina.

Konzistence dat je široký pojem. Samozřejmě věci jako transsakce, spouště, omezující podmínky nebo referenční integrita věci prospívají a MySQL je povětšinou nemá. Ale rozumné webové věci opravdu jde v MySQL napsat. Že se u toho člověk zapotí, to může být pravda; a může být pravda i to, že ho to bude stát více úsilí než při použití "schopnější" databáze.

Důvod, proč jsem začal rozebírat právě MySQL je velmi prozaický - přál si to Linuxsoft. Cílem celého tutoriálu je naučit lidi základy použití PHP a nějaké databáze. František chtěl MySQL a já mu rozumím, tak jsem to tak začal psát.

Osobně si poslední dobou trochu hraju s MaxDB, dost zajímavá věcička, má to snad všechny vymoženosti, jen se to moc nepoužívá. Takže uvidíme - třeba se časem na Linuxsoftu objeví článek: "XXX důvodů, proč nepoužívat MySQL". Ale to už nebude v seriálu o PHP.

A ruku na srdce: K vysvětlení SELECT * FROM TABULKA WHERE x=y ORDER BY Z nám stačí prakticky libovolná databáze.

Důvody pro volbu MySQL celkem chápu a to, že byla zvolena MySQL, by mne samo k reakci nevyprovokovalo. Důvodem byl způsob, jak je to v článku prezentováno - že jsou určitá kritéria a MySQL je splňuje "jasně nejlépe". Pokud bych nevěděl o databázích, vyložil bych si ten odstavec tak, že MySQL toho prostě "umí víc" (i když to tak určitě nebylo myšleno). Protože bych byl nerad, aby čtenáři získali tento mylný dojem, pokusil jsem se formulaci z článku svou reakcí upřesnit.

To je úplně v pořádku, od toho tady ta diskuse je.

Nativni podpora PostgreSQL bude ve verzi 7.5, na kterou uz asi nebudeme muset cekat prilis dlouho. Kolega to zkousel v vyvojove verzi a byl pomerne spokojen.

neni dobre podcenovat. Napr. Interbase a jeho nastupce Firebird az do nedavne doby jinou architekturu nez classic (jak souborovemu pristupu u Firebirdu rikaji) pouzitelnou nemely (ted v 1.5 uz je superserver bez podpory SMP a pouze ve 32bitove verzi jakz takz pouzitelny).

Bez ohledu na to jsem na teto (v autorove terminologii "souborove") databazi videl postavene obludne velke systemy a zminene problemy s vice soucasne pracujicimi uzivateli jsem nepozoroval :) A to tech uzivatel byly stovky.

Já jsem ten termín "souborová databáze" pochopil trochu jinak: že souborovou databází se rozumí databáze, kde aplikace přistupuje přímo k souboru (souborům) s databází. A to u Firebirdu nastává pouze u "embedded" verze (pouze FB 1.5, FB 1.0 ani InterBase tuto variantu nemají), kdy je server implementován v dynamicky sdílené knihovně, kterou je možno přilinkovat k aplikaci a distribuovat s ní, aniž by bylo třeba instalovat a spouštět server. S CS architekturou se tohle neděje, tam je normální client-server komunikace přes TCP; rozdíl mezi SuperServer a Classic Server je podobný jako u Apache mezi "ServerType standalone" a "ServerType inetd" - SS funguje jako samostatný démon, u CS jsou jednotlivé procesy spouštěny z inetd. Nevím, co rozumíš nedávnou dobou, ale SS jsem používal od chvíle, kdy jsem se poprvé dostal k betám IB 6.0, tj. někdy od jara 2000, a neměl jsem vážnější problémy (na víceprocesorové počítače nemám :-( ). Na SMP systémech to funguje taky, jediný problém je v tom, že SS neumí efektivně rozložit zátěž mezi procesory, takže drtivá většina (jeho) zátěže visí na jednom procesoru. Pokud nejde o vyhrazený server a jsou tam jiné procesy, které dokáží zbylé procesory vytížit (Apache, middleware), nemusí v tom být problém, jinak je vhodnější použít CS architekturu.

Poslední vývoj Postgre jde skutečně zajímavým směrem. Budu to sledovat.