Vlákno názorů k článku MySQL vs PostgreSQL vs Firebird od Richard - Takéto benchmarky sú dosť nezaujímavé a nepraktické. Mám...
-
Richard (neregistrovaný)Takéto benchmarky sú dosť nezaujímavé a nepraktické. Mám za sebou dosť veľa aplikácií v MySQL, PostgreSQL a v Oracle aby som vedel čo je pre vývoj a nasadenie aplikácií dôležité a čo nie.
Ďaleko viac ako rýchlosť si na databázach cením spoľahlivosť a bezproblematická práca s danými databázami. V 90. rokoch som nedal dopustiť na Oracle ale to bolo v časoch client-server aplikácií, keď bolo dôležité aby server zvládal veľké množstvo pripojených užívateľov a časť logiky aplikácie bola písaná v triggroch a stored procedúrach. V súčasnosti keď sa robia viacvrstvé aplikácie sa celá logika umiestnená na aplikačnom serveri. Použiť stored procedúru je dosť nevhodné.
V súčasnosti ale nevidím ani jednu výhodu Oracle pred MySQL. S Oraclom bývajú niekedy dosť vážne inštalačné problémy, najmä v kombinácii s jeho vlastným aplikačným serverom. Oracle je pomerne dosť veľký žrút zdrojov - zatiaľ čo pri MySQL si môže každý programátor nainštalovať svoj vlastný server na počítač. MySQL má veľmi jednoduché možnosti na export a import (oproti Oracleovskemu exp a imp kde neexistuje jednoduchy export a import dat bez zbytocneho balastu) a pri pouźití ISAM tabuliek je možné si priamo kopírovať data bez ohľadu na OS a verziu MySQL.
Nechcem tvrdiť že MySQL je dokonalá, už ma tiež raz alebo dva krát sklamala ale zistiť kde je chyba a opraviť konfiguráciu je vďaka jednoduchej príručke a širokej komunite jednoduchšie ako v Oracle.
Čo sa týka PostgreSQL tak sa mi zdá trochu nekonzistentná. Ako keby každý programátor PostgreSQL čo mal nejaký nápad tak ho do implementoval bez ohľadu na nejaké koncepčné riešenie (napríklad syntax príkaz v commandline clientovi nemá nič spoločné s SQL). Pri nasadení novej verzie sa mi napríklad stalo, že sa zmenila syntax (pre LIMIT) a musel som v aplikácii opravovať SQL príkazy. Nekonzistetná je aj príručka. Keď som hladal CREATE TABLE tak ako prvú som našiel stránku http://www.postgresql.org/docs/8.0/interactive/tutorial-table.html kde vôbec nie je odkaz na stránku, ktorú som naozaj potreboval: http://www.postgresql.org/docs/8.0/interactive/sql-createtable.html. O problémoch, ktoré boli s inštaláciou predchádzahjúcej verzie na windowsoch by sa dal napísať samostatný článok.
Pri tvorbe ponuke zákazníkom vždy doporučujem MySQL - ale aj tak sa 90% percent zákazok robí v Oracle :) -
honza (neregistrovaný)[...]V súčasnosti keď sa robia viacvrstvé aplikácie sa celá logika umiestnená na aplikačnom serveri. Použiť stored procedúru je dosť nevhodné.[...]
V diskuzi k mysql na heise.de je asi 80 prispevku k teto problematice. Zhruba 80% respondentu NENI vaseho nazoru. I v jinych diskuznich listech je obdobne mineni. Nezda se Vam to podivne? -
rezna (neregistrovaný)tady si dolovim tezce nesouhlasit ;) - na vykon se sice v urcite mire nehledi, ale hledi se na spolehlivost a hlavne na jednoduchou konfigurovatelnost byznys vrstvy s tim ze pokud mate slusny model ulozeni byznys objektu (napr. XML nebo vlastni textovy format) tak jste schopen z neho generovat i strukturu DB a tim vlastne vydefinovanim jedne vrstvy pokryjete ihned vrstvy 2 coz u stored procedur je trocha mimo ;) - SP maji mozna o neco vyssi vykon ale zase to jejich debugovani je silene a spousta obecnych resenich ktere se v nich pisou je uplne silena.
-
rezna (neregistrovaný)jasne - pokud SP prinese urychleni z n^3 na n*log(n) - OBRAZNE RECENO - tak ji lze aplikovat - ale jde o to ze min. 90% byznys prace by mela obhospodarovat skutence oddelena byznys vrstva a ne DB protoze co kdyz se v pulce projektu zjisti ze nasazena MySQL nestaci a je potreba neco vetsiho - potom by to bylo dost v pytli byt zavisly na jedne DB
-
Petr (neregistrovaný)Ja to slovo "zrychleni v radu" ctu jako "zrychleni desetkrat" ("o rad"), ne jako "prechod na en-log-en". A musim rict, ze je sakra rozdil, jestli batch job, ktery se spousti denne, bezi tri hodiny nebo tricet hodin.
Psani jednoduche DB vrstvy a slozite aplikacni vrstvy vypada dobre na papire, dokud nezjistite, ze si nejste az tak uplne jistej, co delat s gigabajty dat, ktere byste z databaze musel vytahat a zase do ni vracet. (Samozrejme ted nemluvim o webshopu :-)) -
Richard (neregistrovaný)Ne, nezda. Myslim, ze diskusii o databaze sa vacsinou zucastnuju ludia ktori o databazach vedia vela a problemy, ktore ma aplikacia riesit casto riesia prostriedkami, ktore ma databaza. Musim priznat, ze aj som to tak kedysi robil. Ale ak mam business logiku na aplikacnej vrstve, tak nemam vela dovodov pouzit ulozene procedury alebo triggre.
-
benzin (neregistrovaný)Nesouhlasim s Vami. Je to databaze, ktera se stara o konzistenci dat. Pokud tento problem presunete do Aplikace, muze se Vam velmi jednoduse stat, ze nekde neco malo opomeneta a data budou nekonzistentni.
Netvrdim, ze vsechno se musi delat v SP, ale operace, ktere souvisi s konzistenci dat, je nutne delat primo v SP a Triggrech.
P.S.: Casto se stane, ze si zakaznik najme mensi firmicku na sprogramovaniho nejakeho prevodoveho mustku, ten se pak muze rozhodnout pro primi pristup k datum v DB (misto pouziti nedokonalych exportu/importu), paklize nejsou SP a Trigeri udelane spravne, muze se lehce stat, ze se data rozbiji. Pak se muzete dohadovat kde udelali soudruzi z Polske Demokraticke Republiky chybu (kdyz ani nevite, ze vam tam nekdo hrabe primo). -
rezna (neregistrovaný)pozor ale mluvime jeden o A a jeden o B - jednak se tu resila byznys vrstva - tedy aplikacni logika a ta do DB urcite nepatri, druha vec je databazova vrstva zajistujici konzistenci dat jako jsou spravne FK klice, ukladani kopii radku pri zmenach apod. - tohle do DB urcite patri - do toho by zase byznys logika nemela co sahat...
-
rezna (neregistrovaný)> a pri pouźití ISAM tabuliek je možné si priamo kopírovať data bez ohľadu na OS
> a verziu MySQL.
mno jasne ISAM jsou super hlavne kdyz se vam snazi dva uzivatele z 6000 snazi pristoupit k jednomu radku tabulku v tom stejnem momentne nebo nedej boze potrebuju rollbacknout transakci ktera tam neexistuje ze ;)
ČLÁNKY DO MAILU