PostgreSQL vs MySQL - jakie są wasze doświadczenia

0

Cześć,
mam pytanie do osób, które mają doświadczenie z MySQL oraz PostgreSQL - jakie są wasze opinie o obu bazach? Czy któraś z nich stwarza większe bądź mniejsze problemy? Którą bazę byście wybrali i dlaczego do większego projektu www? Wydaje mi się, że MySQL jest dużo bardziej popularne, ale dlaczego? Czy tylko wydajność ma tu jedyne znaczenie czy są również inne zalety? Na co należy uważać korzystając z danej bazy danych (może powyższe silniki mają jakieś nieoczywiste rzeczy stwarzające problemy)?
Głównie chodzi mi o to, który typ bazy jest bardziej przyszłościowy, mniej problematyczny i w który lepiej zainwestować czas?

Z góry dziękuję za podzielenie się waszymi opiniami.

1

Pytanie co to dokładnie ma być za aplikacja. Ja bym wybrał postgresa ale jak nie potrzebujesz jakis złożonych sqlek robić to mysql tez da radę.

8

@Kofcio:

Popularność MySQL nie do końca ma fundamenty w obecnym stanie baz danych (wyrównały się do pewnego stopnia), ale w przeszłości.

Była to szybka bada danych na ówczesnych słabszych serwerach internetowych, kosztem np transakcji, skupienia programisty na niskopoziomowych ficzerach, zgody na egzotyczne wybory inżynieryjne (locking albo całych tabel, albo wcale itd) itd.
W latach hen-hen miała rzeczywiście przebitkę szybkościową x2 x3

Z czasem MySQL dojrzała w ficzery (w tym transakcje, choć nadal z mała gwiazdką u dołu) więc nabrała tłuszczyku, Postgress przyśpieszył. Dziś zależnie od testów są porównywalne z niewielkimi różnicami.
MySQL od dawna z kontrowersyjnymi licencjami (swoją czy po wchłonięciu przez Oracla), Postgres prawdziwe open source.
Forkiem MySQL jest MariaDB, jest to fork głównego pierwotnego autora.

Dedykowanie swojej osoby (jako dorobek intelektualny) pod MySQL jest wejściem w egzotyczny system jedyny w swoim rodzaju - gdy Postgres zawsze miał ważny cel, aby być maksymalnie kompatybilnym ze standardem i innymi implementacjami, w tym wcale udane próby emulowania w swojej wersji języka Oracla (mnie to ani parzy, ani ziębi, ale szacun)

0

@ZrobieDobrze Czyli jeśli dobrze rozumiem Ty rekomendujesz Postgresql-a?

2
Kofcio napisał(a):

@ZrobieDobrze Czyli jeśli dobrze rozumiem Ty rekomendujesz Postgresql-a?

Tak / Nie / Zależy

Nie odpowiedziałeś na głos @S4t

Jak projekt to studencka bazka do meczów na 5 tabel, nie ma znaczenia

a) czy kiedykolwiek podejrzewasz o rozwiniecie do procedur bazodanowych / wiesz, że nie, nigdy
b) czy w otoczeniu biznesowym wybór już został dokonany (w ekosystemie i tak jest jedna z nich). Roma locuta clausa finita
c) w jakim języku projekt, i czy masz warstwę obiektowo-relacyjną, i jaką

Dopiero potem idzie porównanie ficzerów. W skrajnie specjalistycznym projekcie to może być decydujacy argument.

Ale prawdą jest, że Posgres jest bardziej main-stream

0

Postgres jeśli już musisz mieć relacyjną.

0
ZrobieDobrze napisał(a):
Kofcio napisał(a):

@ZrobieDobrze Czyli jeśli dobrze rozumiem Ty rekomendujesz Postgresql-a?

Tak / Nie / Zależy

Nie odpowiedziałeś na głos @S4t

Jak projekt to studencka bazka do meczów na 5 tabel, nie ma znaczenia

a) czy kiedykolwiek podejrzewasz o rozwiniecie do procedur bazodanowych / wiesz, że nie, nigdy
b) czy w otoczeniu biznesowym wybór już został dokonany (w ekosystemie i tak jest jedna z nich). Roma locuta clausa finita
c) w jakim języku projekt, i czy masz warstwę obiektowo-relacyjną, i jaką

Dopiero potem idzie porównanie ficzerów. W skrajnie specjalistycznym projekcie to może być decydujacy argument.

Ale prawdą jest, że Posgres jest bardziej main-stream

@ZrobieDobrze w planach jest stworzenie aplikacji wspomagającej zarządzanie firmą oraz księgowość tej firmy. Z jednej strony przez aplikację firma będzie się pośrednio łączyć z bazą danych programu księgowego, w której będzie wiele informacji (to jednak nie jest przedmiotem tej dyskusji) ale jednocześnie ma umożliwić firmie:

  1. wystawianie faktur
  2. zarządzanie magazynem
  3. zarządzanie pracownikami (np. każdy pracownik będzie mógł wnioskować o urlop przez tą aplikację)
  4. wprowadzanie dokumentów księgowych przez klienta (które będzie można później zaimportować do programu księgowego)
  5. zarządzanie firmą (np. lista zadań do zrobienia, komunikacja między pracownikami/grupami/działami itp.)
  6. obiegiem dokumentów
  7. prowadzenie raportów kasowych
  8. komunikacja między księgowością (zewnętrzną) a firmą
    itp.
    Ogólnie taki projekcik po godzinach :P.

Aplikacja kierowana głównie do biur rachunkowych obsługujących wielu klientów.

Jak już zostało to uzgodnione w oddzielnym wątku, na każdą firmę będzie oddzielna baza danych oraz jedna baza będzie konfiguracyjna (w której będą wspólne informacje np. użytkownicy, nazwy baz danych itp.).

Odpowiadając na Twoje pytania:
Ad a) nie jestem pewny czy dobrze rozumiem pytanie, ale prawdopodobnie tak - zakładam wspomaganie się procedurami bazodanowymi.
Ad b) nie, ja jestem inicjatorem projektu i sam decyduję o wyborze technologii itp. Ale więcej dobrego chyba słyszałem o PostgreSQL niż MySQL, dlatego skłaniam się ku niemu.
Ad c) projekt będzie pisany po stronie serwera (WebAp) w C# oraz po stronie klienta również w C# (Blazor WASM).

3
Kofcio napisał(a):
ZrobieDobrze napisał(a):
Kofcio napisał(a):

@ZrobieDobrze w planach jest stworzenie aplikacji wspomagającej zarządzanie firmą oraz księgowość tej firmy. Z jednej strony przez aplikację firma będzie się pośrednio łączyć z bazą danych programu księgowego, w której będzie wiele informacji (to jednak nie jest przedmiotem tej dyskusji) ale jednocześnie ma umożliwić firmie:

  1. wystawianie faktur
  2. zarządzanie magazynem
  3. zarządzanie pracownikami (np. każdy pracownik będzie mógł wnioskować o urlop przez tą aplikację)
  4. wprowadzanie dokumentów księgowych przez klienta (które będzie można później zaimportować do programu księgowego)
  5. zarządzanie firmą (np. lista zadań do zrobienia, komunikacja między pracownikami/grupami/działami itp.)
  6. obiegiem dokumentów
  7. prowadzenie raportów kasowych
  8. komunikacja między księgowością (zewnętrzną) a firmą
    itp.
    Ogólnie taki projekcik po godzinach :P.

Aplikacja kierowana głównie do biur rachunkowych obsługujących wielu klientów.

Jak już zostało to uzgodnione w oddzielnym wątku, na każdą firmę będzie oddzielna baza danych oraz jedna baza będzie konfiguracyjna (w której będą wspólne informacje np. użytkownicy, nazwy baz danych itp.).

Ty chyba nie masz wyjścia tak naprawdę, bo dokumenty księgowe itp nie mogą być trzymane w jednej bazie dla wielu firm. Ale takie rzeczy to tylko z prawnikiem o odpowiednich kwalifikacjach.

1

@Kofcio:

Jak segment "dla firm" to nie MySQL ani nie Postgres ;-P
Trochę świadomie pojechałem w częsciową przesadę. Ale to segment MS-SQL, i te całe dywagacje "a może klient zażyczy sobie kopie swoje bazy z weba itd" tracą część sensu.
Tak, wiem, nie ma tu nigdzie pomysłu wchodzenia wprost na bazę, a przez API sieciowe, ale jednak.

Proba odsprzedaży fragmentow kodu / konsultacji itd dla tych co by się chcieli usamodzielnić (bo np urośli), zakłada to w środowiskach Windowsowych, z akcentem na C# - jak będziesz myślał w PHP "my jesteśmy zagorzali linuksowcy / opensursowcy", to tracisz trochę z szans.

Co do wątku o "mutitenant", przy tym pomyśle na produkt to nie widzę ani milionów klientów, ani tysięcy, setka to bym myslal jako o "dużym sukcesie", realne kilkanaście, a może pięć.
Nie widzę pchajacych się drzwiami i oknami.

0
ZrobieDobrze napisał(a):

@Kofcio:

Nie widzę pchajacych się drzwiami i oknami.

Np żadne biuro ksiegowe nie zajmuje się wnioskami urlopowymi z przyczyn zasadniczych. Mam analizować dalej ?

1
ZrobieDobrze napisał(a):

@Kofcio:

Jak segment "dla firm" to nie MySQL ani nie Postgres ;-P
Trochę świadomie pojechałem w częsciową przesadę. Ale to segment MS-SQL, i te całe dywagacje "a może klient zażyczy sobie kopie swoje bazy z weba itd" tracą część sensu.
Tak, wiem, nie ma tu nigdzie pomysłu wchodzenia wprost na bazę, a przez API sieciowe, ale jednak.

A jakie przewagi nad Postgresem daje mi MS-SQL? Pytanie mnie ciekawi, bo większość programów księgowych siedzi na MS-SQL-u i w sumie jest ok, ale osobiście nie widzę jakiś większych przewag. A robi się problem, gdy baza zacznie się zbliżać do limitu (większość firm działa na wersji express gdzie limit to bodajże 10GB). Ja tych limitów raczej nie przekroczę, szczególnie, gdy dla każdej firmy będzie oddzielna baza,, ale siedzi mi to z tyłu głowy...

Dodatkowo z MS-SQL jest taki problem, że jest chyba tylko pod windowsa(?), a ja nie chcę być ograniczony do konkretnego systemu (jeszcze nie zostało postanowione na czym postawie bazę danych). Dodatkowo Postgres jest w pełni darmowy a to jest dla mnie dość istotne.

Proba odsprzedaży fragmentow kodu / konsultacji itd dla tych co by się chcieli usamodzielnić (bo np urośli), zakłada to w środowiskach Windowsowych, z akcentem na C# - jak będziesz myślał w PHP "my jesteśmy zagorzali linuksowcy / opensursowcy", to tracisz trochę z szans.

Raczej tego nie przewiduję. Mało jest firm, które by się na to porwały - ja robię to hobbystycznie dla siebie i biur z którymi współpracuję lub będę współpracował w przyszłości :). Na rynku są już podobne rozwiązania, ale wydaje mi się, że mogę wnieść coś nowego (mam swoją wizję jak to ma wyglądać). Dodatkowo fajnie jest mieć swoją niezależną apkę, którą można po swojemu rozwijać :)

Co do wątku o "mutitenant", przy tym pomyśle na produkt to nie widzę ani milionów klientów, ani tysięcy, setka to bym myslal jako o "dużym sukcesie", realne kilkanaście, a może pięć.
Nie widzę pchajacych się drzwiami i oknami.

Bo nie znasz rynku :P. Opcja wystawiania faktur, prowadzenia magazynu, panel dla pracowników etc. to jedna część projektu, ale w pierwszej kolejności to ma być taki pulpit managera (wgląd do programu księgowego przez przeglądarkę). Przykładowo właściciel firmy będzie widział nierozliczone pozycje, na jakim etapie jest wprowadzanie jego dokumentów, jakie są podatki - wszystko online. A dodatkowo będzie mógł sobie wystawić fakturkę, prowadzić raport kasowy itd.

Dodatkowo na początkowym etapie ta aplikacja będzie za darmo dla obecnych klientów biur rachunkowych z którymi współpracuję. Ma to zachęcić nowych klientów. Jak projekt uda mi się zrealizować (biorę pod uwagę ryzyko niepowodzenia) to dopiero wtedy będę myślał o jego sprzedaży. Na ten moment to projekt domowy.

ZrobieDobrze napisał(a):
ZrobieDobrze napisał(a):

@Kofcio:

Nie widzę pchajacych się drzwiami i oknami.

Np żadne biuro ksiegowe nie zajmuje się wnioskami urlopowymi z przyczyn zasadniczych. Mam analizować dalej ?

Nie jestem pewny czy dobrze rozumiem co piszesz, ale tak się składa, że z zawodu jestem księgowym i pracuję w dwóch biurach rachunkowych (programowanie to tylko hobby) i wiem mniej więcej co jest potrzebne na tym rynku :).

0

Przewaga MS-SQLa jest głównie taka, że masz umowy, support, etc. które zapewnia Microsoft, ale to oczywiście kosztuje. W bazach danych nie chodzi tylko o wydajność.

Co do tematu.

Kilka lat temu było tak, że MySQL o wiele częściej łapał deadlock-i (https://pl.wikipedia.org/wiki/Zakleszczenie) podczas transakcji niż PostgreSQL który łapał ich zero, realizując to samo zadanie, przy użyciu podobnego poziomu izolacji transakcji, robiłem testy, i to mnie ostatecznie przekonało do przejścia z MySQL na PostgreSQL. Może coś od tego czasu poprawili.

Inna sprawa, to o wiele gorszy planner skomplikowanych zapytań w MySQL niż w PostgreSQL. Nawet przy prostych zapytaniach, w MySQLu musiałem używać "hacków" w postaci instrukcji HINT, żeby wyraźnie powiedzieć MySQLowi z jakich indeksów ma korzystać, bo lubił sobie nie korzystać, albo korzystać nie z tych, które dawały najlepszą wydajność.

Tego problemu w PostgreSQL nie ma, planner jest bardzo dobry nawet dla bardzo zawiłych kwerend, korzysta przy tym z wewnętrznych statystyk, żeby oszacować, który indeks w danej sytuacji będzie najlepszy.

Więc powtórzę to co inni: prosta baza, proste transakcje, nie za duże wolumeny danych i MySQL się nada. Np. jakiś blog internetowy, forum, mały prosty sklep. Większe wolumeny danych, skomplikowane zapytania i obciążające transakcje - lepiej wybrać PostgreSQL.

4

Jak segment "dla firm" to nie MySQL ani nie Postgres ;-P
Trochę świadomie pojechałem w częsciową przesadę. Ale to segment MS-SQL, i te całe dywagacje "a może klient zażyczy sobie kopie swoje bazy z weba itd" tracą część sensu.

Trochę kek patrząc po ilości nowych firm, które idą w DB open-sorce/public-source.

Przewaga MS-SQLa jest głównie taka, że masz umowy, support, etc. które zapewnia Microsoft, ale to oczywiście kosztuje.

Dla MySQLa i Postgresa też masz firmy oferujące support. Dodatkowo masz również możliwość używania hosted-DB i specjalnie się nie przejmować.

0
Kofcio napisał(a):

Dodatkowo z MS-SQL jest taki problem, że jest chyba tylko pod windowsa(?), a ja nie chcę być ograniczony do konkretnego systemu (jeszcze nie zostało postanowione na czym postawie bazę danych). Dodatkowo Postgres jest w pełni darmowy a to jest dla mnie dość istotne.

Od jakiś 3 lat jest MS-SQL pod Linuksa/y, w tym wersja Express

Po umowach / zasadach wsparcia producentów oprogramowania nie widzę, aby miało to entuzjastyczne przyjęcie. Na Windowsach mają desktopy linii Pro w supportowanych wersjach (system nie suportowany przez MS jest również nie suportowany u producenta), MS Servery w kilku aktualnych wersjach, generalnie środowiska dobrze znane.

Linuksów jest w cholerę, nie wyobrażam sobie biznesowej relacji wsparciowej na dowolny z nich, trzeba by mocno ograniczyć. Jedna dystrybucja jest w nastrojach anty-korporacyjnych, inna w rygorystycznych ascetycznym Opensurs GPL, jeszcze inna skrajnie minimalistyczna - albo wybitnie tłusta w typowej instalacji "z pudełka".
Przypomnę specjalne zachody, jakie trzeba było robić do instalacji closed-soursowej Javy na debianach

I jakiego linuksa wybrać do umowy wsparciowej? darmową ale z zapachem "eksperymentalnej" Fedorę *) ? Płatnego Redhata ? Debiana buntującego sie na korpo?
Firma mała-średnia nie będzie miała kilku(nastu) serwerów, aby na jednym z nich zainstalować akurat taką dystrybucję linuksa, jaką wspiera dostawca aplikacji.

*) osobiście nic do niej nie mam, i nigdy nie dostałem "strzała w plecy", ale tam podobno się testują ficzery, które wejdą w płatnego RH.

1

nie wyobrażam sobie biznesowej relacji wsparciowej na dowolny z nich

What? Najpopularniejszy system na serwerach i masz w opór firm oferujących support:

  • Canonical (Ubuntu)
  • Oracle
  • IBM/RedHat
  • Amazon

I jakiego linuksa wybrać do umowy wsparciowej?

Można pójść bezpiecznie i wziąć najpopularniejszą dystrybucję na serwery - Ubuntu. Darmowy, płatny support masz jak chcesz, popularna, dostępna praktycznie na każdej platformie cloudowej, wspierana przez praktycznie każdą firmę oferującą swoje produkty na Linuchach.

Firma mała-średnia nie będzie miała kilku(nastu) serwerów, aby na jednym z nich zainstalować akurat taką dystrybucję linuksa, jaką wspiera dostawca aplikacji.

O maszynach wirtualnych słyszał? Poza tym w dzisiejszych czasach masz mnóstwo hosted-solutions, Dockera, i inne pierdoły, które powodują, że instalacja czegokolwiek jest banalnie prosta. Dodatkowo zdecydowanie łatwiej znaleźć kogoś do obsługi Linuchów niż Windows Server.

2

Ja bym brał postgresa.

1
Riddle napisał(a):

Ja bym brał postgresa.

Ja tez

0

Z kwesti, które jeszcze nie zostały poruszone to brałbym postgresa, bo:

  • częściej go spotykam w nowych projektach, moda jest ważna, bo uczymy się "przydatnych" rzeczy jak i łatwiej znaleŹć programistę na rynku z odpowiednią wiedzą
  • postgres jest popularny jako protokół np. CockroachDB albo nowy AlloyDB od googla. Więc klepanie zapytań w postgresie i ogólna wiedza o architekturze w pewien sposób się przenosi na inne bazy

1 użytkowników online, w tym zalogowanych: 0, gości: 1