Nu am incercat sa fac o comparatie mysql - postgres. Am mentionat ce
m-a deranjat in utilizarea postgres. Recunosc ca in unele puncte as
putea fi subiectiv, asa cum probabil esti si tu.
Pe de alta parte tu iei partea postgres si din reply-ul tau se deduce
antipatia pt mysql. :)
On Wednesday 19 February 2003 01:45 pm, you wrote:
> On Wed, 2003-02-19 at 13:06, Calin Damian wrote:
> > da. lista nu se dorea completa.
> >
> > Ar mai fi de considerat si faptul ca postgres nu este la fel de
> > matur ca mysql iar userland-ul mysql este imbatabil :)
>
> Cu maturitatea. MySQL este mai batran decat PostgreSQL (in productie)
> cu cativa ani buni din cate stiu. Ce vreau sa spun e ca PostgreSQL a
> devenit universal acceptat si mai bine cunoscut doar cu versiunea
> 7.0. Acum, problema e ca nu se poate lua asa ceva ca masura a
> maturitatii. Pentru ca efectiv nu comparam produse similare. MySQL si
> PostgreSQL nu se plaseaza de nici o culoare in aceeasi clasa. MySQL
> compara-l daca vrei cu Interbase. S-ar putea sa iasa invingator acolo
> :)
Functii importante, documentate dar neimplementate. Pt. mine asta a fost
un argument al lipsei de maturitate.
> Acum lamureste-ma, te rog, ce intelegi prin userland la MySQL (sunt
Poate m-am exprimat gresit. Ma refeream la numarul de utilizatori pe
care ii are mysql vs. postgres
> > La Postgres versiunea 7.2 lipseau niste facilitati de bun simt zic
> > eu, gen nu puteai sterge o coloana dintr-o tabela
>
> Right on target. Nu, ai perfecta dreptate. Asta este unul din
> neajunsurile postgresql, uitasem de el.
Nu stiu daca ce e mai sus se vrea o recunoastere sau o ironie.
> > Alte minusuri mari pt. postgres:
> > - docs
>
> Nope, nu sunt de acord. postgresql.org/docs imi da de 2^n ori mai
> multe informatii utile decat doc-urile de la mysql.com. Alea de la
> mysql sunt povesti, nu doace. Am citit la un moment dat un capitol
> intreg, despre foreign keys, in care povesteau pe prima jumatate de
Imi mentin punctul de vedere.
> > - modul de modificare a drepturilor pentru useri si baze de date
>
> Iarasi, nu sunt de acord. Dar aici recunosc ca pot fi biased. Poate
> in definitiv e chestiune de gust.
.... subiectivism? :-/ Mie nu mi se pare.
> > - tot felul de "gotchas" stupide le-as zice, gen: cateodata daca
> > in query-uri nu pui la clauza where apostroafe (') query-urile
> > dureaza de cateva ori mai mult (e vorba de nr. intregi)
>
> Poate fi un caz de casting explicit vs casting implicit. Majoritatea
> query-urilor complexe trebuie ajustate semnificativ pentru a putea fi
> eficient planificate de planner. Un analyze explica multe. BTW, un
Cazul era de genul SELECT smth FROM tabela WHERE
<coloana_integer>=<numar>
> > - e mai putin "periat" (de exemplu, daca iti crapa pc-ul cat rula
> > postgres, la reboot nu mai porneste din cauza ca verifica doar daca
> > exista pid-ul nu si daca ruleaza efectiv)
> >
> :) pidfile rings a bell? :) Tine de distributie. Am patit-o in redhat
da. enervant oricum.
> mai multe ori. Oricum, nu se compara cu bubele uriase de care poti da
> in mysql la un power cycle.
power cycle?
--
...:::::: Calin DAMIAN
....::::: Software Team Leader, Matrix Communications
--
Pentru dezabonare, trimiteti mail la
[EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'.
REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
