Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Postgres vs MySQL
Forum PHP.pl > Forum > Bazy danych
woocash
Co i dlaczego jest lepshe?questionmark.gif
Postgres czy MySQL...
Ludzie moowią mi,że Postgres jest stabilniejszy, bezpieczniejszy itp...
Ale ja sie do MySQL'a przyzwyczaiuem...
Czy musze to zmieniać czy w Postgre jest cos czego nie da sie zrobić w My?
itsme
oooo jest o czym pisac (jestem po malym szkoleniu hihihi)
- Postgres jest wolniejszy o okolo 30%, biorac pod uwage ze zwrot wartosci w zaleznosci od zlozonosci zapytania trwa 0.5 s (strzelam) + 30% = 0.65 s podczas generowania strony chyba nieodczuwalne. I to jest jedyna wyzszosc mySQL-a nad Postgresem

- Postgres ma: mozliwosc wpisania funkcji wewnatrz jego wywolanych automatycznie podczas jakiegos zdarzenia np. loguje sie czlowiek na strone wpisujesz jego zalogowanie do tabeli SESJA zas Postgres sam zapisuje odpowiednie dane w tabeli historia_logowan i to sie dzieje poza php
- Postgres ma widoki - podobnie jak kwerendy w Accessie
- Postgres ma relacje
- Postgres podzapytania
- Postgres ..... wiele wiele rzeczy
- sadze ze dragossani bedzie mogl sie tu wykazac smile.gif badal ten temat
dragossani
Skoro już mnie wytykają palcami to napiszę parę słów:

Przewagi MySQL'a:[list]
Szczav
A czy są jakieś inne darmowe, godne uwagi bazy danych?
mbik
dragossani/ rozumiem, ze jestes glebiej zorientowany w temacie ;-]
Tez interesuje mnie porownanie tych 2 DB. Jak dotad uzywam mysql, ale zastanawiam sie nad pg (jeszcze nie sprawdzalem) - wydaje sie, ze jest kompletniejszy i upraszcza wiele spraw - zawiera gotowe rozw., ktore w mysql trzeba tworzyc samemu.
Jednak spotkalem sie z wieloma opiniami, ze PG jest mniej stabilny od mysql, zdarzaja sie bledy i gubienie danych (!!! - to mnie nastawia szczegolnie podejrzliwie) oraz w wielu sytuacjach jest znaaczenie wolniejszy od mysql.

W przypadku WWW ww. problemy nie maja, az tak duzego znaczenia - konsekwencje bledow sa mniejsze. Jednak w sytuacjach, kiedy DB jest podstawa np. intranetowych systemow zarzadzania firma, kazde zafalszowanie, czy zagubienie informacji moze byc bardzo niebezpieczne.

Czy masz jakies glebsze doswiadczenia w tej materii?questionmark.gif
uboottd
Do komentarza dragossiniego dodam tylko takie uwagi:

- sprawdzanie kluczy obcych w mysqlu jak najbardziej jest i to od dawna
- po obejrzeniu pg wydaje mnie sie ze system uprawnien w mysqlu jest jednak lepszy.
- pg ma dosc powazny problem z transakcjami w trybie serializable (dopuszcza phantom reada, czego robic mu nie wolno), mysql tego nie ma, ale potrafi zaskoczyc interpretacja locka na wierszu (ale nie powoduje to blednego dzialania).
- mysql ma UNION od 4.0 ktory jest juz produkcyjny.
- podzapytania sa od 4.1.0 ale to jeszcze alpha, takze podaje to jako ciekawostke na razie.
dragossani
Do mbik: Nie słyszałem ani nie spotkałem się z gubieniem danych przez Postgresa. Polecam poza tym dobry artykuł zawierający porównania stabilności i wydajności MySQL i Postrgres w środowisku webowym.

Do uboottd:
- Obsługa kluczy obcych (podobnie jak transakcje) jest rzeczywiście obecna (choć na pewno nie od tak dawna jak w Postgresie - od wersji 3.23.43b mianowicie), ale trzeba korzystać ze specjalnego, innego niż domyślny typu tabeli (InnoDb).
- System uprawnień w MySQLu dopuszcza na przykład zapytania do bazy innej niż ta, do której jesteśmy zalogowani. Niezbyt szczęśliwe rozwiązanie. W bazie Oracle, która jest swego rodzaju wzorcem dla silników bazodanowch, nie dopuszczono do takich paradoksów. Podobnie w Postgresie.
- UNION doszedł rzeczywiście w wersji 4.0 ale zapomniano przy okazji o zaimplementowaniu przecięć (INTERSECT, EXCEPT).
- Podzapytania - tak jak napisałeś.
mbik
dragossani/ na ten art. trafilem juz dawno, ale dzieki. Nie rozwiewa on moich watpliwosci glownie ze wzgl. na nie najnowsze (...) wersje obu testowanych DB. Chcialbym zobaczyc porownanie obecnie dostepnych mozliwosci i cech. 3 lata to sporo czasu na zmiany.
Wiekszosc wypowiedzi nt. mysql/pg odnosi sie do zastoswan zwiaznych z WWW, a mnie ciekawi jak te DB sprawdzilyby sie w innych warunkach (np. jak w moim wczesniejszym przykladzie). Na pierwszy rzut oka pg wyglada na tym polu lepiej (wiecej przydatnych funkcji zaimplementowanych juz dosc dawno - sprawdzonych), ale te "data corrputions"... :-]
uboottd
Cytat
- System uprawnień w MySQLu dopuszcza na przykład zapytania do bazy innej niż ta, do której jesteśmy zalogowani. Niezbyt szczęśliwe rozwiązanie. W bazie Oracle, która jest swego rodzaju wzorcem dla silników bazodanowch, nie dopuszczono do takich paradoksów. Podobnie w Postgresie.


MySQL dopuszcza ci zapytania dokladnie do tego do czego pozwolisz robienie zapytan. Gdzie tu widzisz paradoks ? Jak danemu uzytkownikowi dasz prawa do dwoch baz to czemu nie pozwalac mu na korzystanie z nich jednoczesnie ?
dragossani
Powiem tak: mnie też się podoba w MySql łączenie się z paroma bazami na raz, ale (1) wydaje mi się podejrzene, że inne bazy danych tego nie obsługują (czyżby wreszcie MySql pionierem?), (2) skorzystanie z tego przykuło mnie kiedyś do MySql'owej platformy - napisałem projekt korzystający z tego dobrodziejstwa i nie dało się tego potem przenieść na inną bazę danych. Swoją drogą, czemu w takim razie służy komenda USE w MySql? Okazuje się, że w sumie niczemu... 8O Generalnie jak się temu przyglądam, widzę że MySql traktuje wszystkie bazy jako wyłącznie twory lokalne, a inne silniki bazodanowe widzą bazy jako osobne jednostki - niekoniecznie na tej samej fizycznie maszynie. MySql usztywnia w ten sposób możliwości składowania danych. Dlaczego w Postgresie tego typu zabawy znajdują się na liście TODO w dziale Exotic? Ponieważ nikt nie bierze pod uwagę, że można sobie olać miejsce składowania danych i po prostu spytać do dwóch baz na raz (jak to ma miejsce w MySql). Wszystkie pomysły opierają się co najwyżej na próbie wykonania kolejnych połączeń z poziomu jednego zapytania. Pojawia się wtedy ryzyko, że baza znajduje się na zdalnej maszynie i trzeba myśleć o optymalizacji przesyłu danych. Warto poczytać sobie stosowny wątek na forum rozwojowym Postgresa.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.