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 :)
Acum lamureste-ma, te rog, ce intelegi prin userland la MySQL (sunt de
buna credinta, chiar nu stiu sigur la ce te referi!)
Daca te referi la libraries;
ehe! mie mi se pare programarea in C cu pg un adevarat deliciu. In PHP
mysql intotdeauna a fost in urma cu un pas. Iar Perl nu se pune la
socoteala :) DBI teoretic rezolva tot, dar din pacate, ca si Pear DB, nu
ofera unele facilitati critice in PostgreSQL - acces la blobs, lastoid,
etc. Asta e neajuns al oricarui abstraction layer care vrea sa ofere
acces si la un lowerclass ca MySQL si la Oracle in acelasi timp.
Daca te referi la admin tools;
am dezavantajul ca nu folosesc din principiu php(my|pg)admin. Dar cand
ajung in shell-ul mysql ma simt ca si handicapat; in pgsql faclitatile
oferite sunt cu mult mai multe.
> 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.
> 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 pagina care (nu) e
implementarea lor si pe restul de 3 isi justificau asa-zisa alegere.
Baiteii sunt imbatabili, orice ar implementa, ca ei e mai bine. Pentru o
disertiune similara vezi si capitolul despre comments. Mi se pare foarte
interesant cum intotdeauna ei au grija sa omita in discutiile lor acel
element esential care lor nu le convine (spre exemplu, comment in SQL
standard se incepe cu double-dash, dar nicaieri nu se spune asta pe
pagina corespunzatoare de la mysql docs).
PostgreSQL are o organizare logica a doc-urilor satisfacatoare, si cu un
minim de experienta in ierarhia asta poti sa gasesti cam tot ce doresti
oricand. Cautarea e un minus :)
> - 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.
> - 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 lucru
pe care eu nu l-am crezut multa vreme, vacuum analyze executat o data pe
zi sau similar are un impact covarsitor (pozitiv) asupra performantei
pentru bazele postgresql complexe.
> - 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 de
mai multe ori. Oricum, nu se compara cu bubele uriase de care poti da in
mysql la un power cycle.
> - etc.
?
--
George Barbarosie <[EMAIL PROTECTED]>
intelinet.ro SRL
--
Pentru dezabonare, trimiteti mail la
[EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'.
REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
