No własnie tak sie zastanawiam co jest lepsze mysql czy PostgreSQL. A wy co o tym sądzicie?

Koniecznie chcesz zacząć kolejną świętą wojnę? :wink:
http://brainscraps.com/faq/pg_my.html

HejKazdemu wg potrzeb. Postrzebujesz protszej bazy ale szybszej, wybierasz MySQL. Chcesz miec spojne tabele i czesc pracy przerzucic na baze (np ybieranie okreslonych danych) - uzyj postgresa.

Pozdrawiam

<FLAMEWAR!!!!!!! ;P >
PostgreSQL rzadzi
</Flamewar>

A teraz na powaznie (powaznie != obiektywnie, wiec prosze nie krzyczec).
Jezeli potrzebuejsz sie nauczyc porzadnego sql'a ze wszystkimi feathurami to wybierz postgresql'a. Mysql jest dobry, jezeli masz baze selectywną i nie wykonujesz insertów. Chociaz w tym przypadku PostgreSQL tez jest lepszy (aczkolwiek nie tak miazdzaco jak przy prawdziwej bazie ze zmienna content). Polecam jednak wersje 7.4b, bo poprawiono w niej wydajnosc subselectow (nie wiez co to?, wybirz postgresql'a, a sie dowiesz) ktore zwracaja wiecej jak kilka 1e3 wartosci. Rowniez mozliwosc uzywania funkcji, kursorow, widokow oraz skomplikowanych joinow i stosowania skomplikowanych zaleznosci poprawiaja sytuacje postgresa jako bazy selectywnej.

Jezeli chcesz robic inserty, delety itp, itd to nawet nie mysl o mysql'u (zreszta, najlepiej i tak o niej nie mysl). Mozliwosc stosowania tranakcji, triggerow, checkow wielorodzajowych, funkcji sql'a i w paru innych jezykach jeszcze miarzdzy mysql na glowe w 100%. Co prawda postgresql jest troche wolniejszy, ale przy tym co podalem wyzej to mam to tu i tam .

A tak ps to jestem ciekawy ile w mysql'u zajmuje usuniecie 20tys rekordow za pomaca `delete from cascade`, podczas, gdy do kazdego rekordu w tablei sa odpowiedniki w dwoch drugich tabelach polacznoe za pomaca fk i `on delete cascade`. <-- ~5min na postgresql 7.3.4 (dlatego wole dac drop table i create table <-- ~2sek).

Ale postgres ma ta wade, ze trzeba co jakis czas robic VACUUM, ktory przy sporej bazie i duzej "odwiedzalnosci serwera" moze byc klopotliwy.

FiDO: zawsze mozna zrobic tak:
Przniesc wszystko na baze zastepcza.
Zrobic VACUUM na bazie glownej.
Zsynchronizowac obie bazy (dodac do sterej to co doszlo podczas VACUUM)!

Jabol: Jak piszesz zapytania jakbys zelazo pilowal to i "wychuchany" PgSQL nie pomoze. Jak troche przy tym myslisz to nagle okazuje sie ze przewagami Pg, ktore warto brac pod uwage sa widoki i procedury storowalne. W My subselecty sa juz w drodze, jak wykazalem na kilku przykladach okazuje sie ze wiekszosc podzapytan mozna zapisac sklejeniem (a na testach wyszlo ze to moze byc nawet szybsze od subselecta), wiec ta roznica wlasnie zanika. Reszta to juz marketing. A sprobuj np. dac zapytanie do dwoch baz na raz.

A do nauki to wlasnie bym jednak polecal MySQL-a - jest prostszy, latwiejszy w uzyciu i mniej wymagajacy od usera. Jak sie dojdzie do problemow bez naturalnych rozwiazan sqlowych to wtedy czas na przesiadke.

Poza tym wez lepiej sie uspokoj, dawno nie widzialem takiego fanatyka jak Ty, a to zawsze jest niezdrowe.

A i pisz po polsku bo czasami tego czytac sie nie da.

m.in. wlasnie za to nie lubie mysql'a (jak i Wina) nie boj sie. Nie zamierzam porwac samolotu . Ja jestem bardziej zwolennikiem niz fanatykiem

Ad1. jakies dziwne uprzedzenia masz...

Ad2. Pojdzmy na kompromis: fanatyczny zwolennik


A co do Twojej propozycji rozwiazania problemu VACUUM to chyba nie jest ono najlepsze.. Jesli baza jest duza (a takie jest zalozenie) to jej kopiowanie do nowej bazy troche potrwa i tez jest to obciazenie dla systemu (nie wspominajac o tym, ze zawsze musisz miec odpowiednio duzo wolnego miejsca na dysku, zeby czasem przenoszenie sie nie wykrzaczylo...).