Luben Karavelov wrote: > > On Wed, Oct 17, 2001 at 12:34:39PM +0300, Vesselin Kotarov wrote: > > pak ottam: > > "NOTE: This Document was written in May 2000. Thus, it is outdated and does > > not represent the latest data concerning MySQL. I will attempt to find time > > to rewrite this with more current information soon (August 10th, 2001)" > > > > mdam .. w samoto nachalo zwuchi dosta glupawo, no natatyk qwno na choweka mu > > proswetwa za Inoobase tablicite i kakwo tochno mogat te. w krajna smetka ako > > pyk chowek se zachete i iz mysql manuala shte stigne do izwoda, che mysql ne > > e nikak losha baza ot malyk do sreden tip. a ako iskash da prawish neshto > > ogromno - horata sa izmislili i ogromni bazi :) > > > az sym polzval kakto myslq taka i postgresql. zatova da vzema i az da se izcepia. > ot mai 2000 godian i postgres e naprednalo mnoooogoooooooooo. eto i niakoi razmisli > otnosno postgresql/mysql > > conra mysql: > > 1. transakcii ne znachi che se minavat acid testovete. > 2. mysql niama "referential integrity" - demek relacionnata baza da ne mozhe da ne > e svyrzana, demek da ne mozhe da ima bezmislici v neia - tova e d v acid Durability. > 3. developerite na mysql sa tvyrdo protiv trigeri i malko po-malko protiv stored > procedures. niamash li trigeri, niamash i "referential integrity", demek cialata > logika na rabota na bazata danni da e v samata baza danni, a ne da se razchita, che > prilozhenieto shte deistva corectno. > 4. standartno instalirana mysql oshte polzva edinstveno table locks pri >update,insert. > > pro postresql: > > 1. postgresql e po-byrza ot mysql. vypreki razprostranenoto mnenie za mysql kato > po-byrza. sega shte obiasnia: > a/ pri smeseni select/update se polzva niama table-lock a se polzva edna technika > podobna na phazing tree v ufs na freebsd - ne se lock-vat dori redove ot bazata. > b/ pri prost select postgres e maaalko po-byrza ot mysql. > c/ pri neoptimiziran slozhen select e 4-6 pyti po byrza. > d/ ako se zameni izpolzvania v mysql workaround za lipsta na sub-select sys sobstveno > sub-select v postgresql, skorostta stava veche 8-10 pyti. > e/ tova go znam ot opit, s realni bazi a ne zashtoto taka iskam. > 2.kritikite za 8k limit na record se otnasiat kym aktualnata v nachaloto na 2000g. > versia 6, a ne kym segashnata 7. > 3.v postgresql principno ne mozhe da ima zaguba na informacia, ponezhe se se polzva > taka narechenia WAL-Write Ahead Log - neshto podobno na jurnalite na failovi sistemi. > 4. postgres e extensible - mozhesh da si napishesh svoi sobstven tip danni, kakto i > operatorite i funckiite za rabota s nego. mozhesh da polzvash ezhici kato pl/pgsql, > perl,tcl,c etc. > > pro mysql > > 1. instalira se lesno i se administrira lesno. > > contra postgresql > > 1. ne se instalira tolkova lesno i ne se administrira tolkova lesno kolkoto mysql. > tova spored men ne e tochno nedostatyk, a podhod - kolkoto poveche features ima edna > RDBMS, tolkova i po-trudno stava instalaciata i administraciata i. > > ima neshta koito lipsvat kakto i na mysql, taka i na postgresql. kato primer samo - > clysterirane,reliable and non-stressing backups and archivation, etc. > > ami tova e...
Izlizame offtopic no da kazha i az neshto :) Summary-to koeto si napravil po-gore e chudesno. Obshto wzeto az sam 100% pro Postgres. Edinstveno koeto mi triabva na men, a lipsva vav postgresa sa barzite aggregatni funckii (count, primerno) i "update in a row" toest pri update na int4 pole da ne lepi tupple a da updatva in place. Tova poslednoto pishe che shteli da go opraviat. Inache za mysql niamam kakvo tolkova da kazha osven che mi e zhal za adminite koito se mychat da vlachat saitove na nego :) Izobshto ne skalira dobre za seriozna rabota da ne govorim che TABLE lock-a e ubiistven. =========================================================================== A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers) http://www.linux-bulgaria.org/ Hosted by Internet Group Ltd. - Stara Zagora
