Którą bazę SQL wybrać?

Baz SQL jest wiele, w większości mają podobne zastosowania, załóżmy czysto teoretycznie, że zaczynamy coś czysto od zera i nie jesteśmy związani żadnymi wymogami, którą bazę wybrać?

Zakładam, że jest sens użyć SQLa, czyli że odpowiedź nie brzmi: żadną ani: Jakiś NoSQL

Niewiele wiem o różnicach między bazami, ale na intuicję scharakteryzowałbym je tak:

• Postgres: Cool kid on the block, defaultować do niej. Baza robiona przez ludzi, którzy mają mózgi, w przeciwieństwie do pozostałych baz (tak się wypowiedział na jej temat wykładowca na uczelni). Darmowa. W zasadzie najlepsza?
• MSSQL: Jak się robi coś w dotnecie? Oprócz tego płatna, sensowna ale nieco gorsza alternatywa Postgresa?
• OracleDB: Jak MSSQL, tylko do Javy
• MariaDB / MySQL: Bardzo popularne, ale raczej marne. Czemu wszyscy tego używają? MariaDB jest jak MySQL, ale lepsza.
• SQLite: Jedno zastosowanie: Jeśli chce się uniknąć serwera bazy danych, bardzo by chciało zmieścić się w DLLce (np. w przypadku przeglądarki internetowej ma to sens). Oprócz tego NIE

Czyli: Albo wiesz, co robisz, i bierzesz to, co ci potrzebne; albo, jak po prostu potrzebujesz JAKIEJŚ bazy, to idź w Postgresa? (Albo cokolwiek jest domyślnego w twoim środowisku, tj. jeśli dotnet wepchnie ci mssql to niech tam będzie)

Domyślam się, że to mogą być głupoty, co napisałem. Jakie byłoby więc sensowniejsze podsumowanie dostępnych baz?

Domyślam się, że przy zaczynaniu nowego projektu to może być częste zjawisko: potrzebuje się JAKIEJŚ bazy, ale nie ma się eksperckiej wiedzy na temat baz, więc wyboru trzeba dokonać "na czuja". Stąd myślę, że jakieś ogólne guidelines mogłyby być przydatne

A może odpowiedź brzmi: To nie ma najmniejszego znaczenia? I tak będzie się najprawdopodobniej używać jakiegoś ORMa. Czy ORMy abstrahują bazy na tyle dobrze, że różnice zaczynają być nieistotne, można równie dobrze rzucić monetą?

1. MSSQL nie jest zawsze płatny. Jest wersja Express (10GB bazy, ~1GB RAM (w rzeczywistości więcej), chyba 1 rdzeń CPU ???)
2. Nie ma najmniejszych przeszkód pracy MSSQL z Javą, działa wyśmienicie, nie wiem o czym piszesz.
3. Przewaga MySQL wywodzi się z zastosowań internetowych. Wytworzyła się znaczna ilość ludzi którzy ją znają (albo im się tak wydaje). Wieki, wieki temu zupełnie bez-transakcyjna (ale szybka). Obecnie transakcyjność gorsza niż MSSQL (w MS transakcyjne są również altery)
4. Sympatyzował bym z Postgresesem, ale rodzaj produktów w moim portfelio jest jaki jest, i niekoniecznie dobrowolnie pracuję z pozostałymi
5. Oracle ma też wersję express, i obserwuję instalację na tym, nie jest źle (wcale nie java ani *xiksy, Windows i coś a'la delphi. Dośc egzotyczny wybór producenta programu)

Te intuicje to są oparte głównie na jakiś plotkach czy blednych przeświadczeniach, jak wiązanie bazy z platformą. Na moją intuicje to nic co tam napisałeś w tym podsumowaniu nie jest prawdziwe. Ani wyższość Postgresa, ani kiepskosc MySQL, ani wyzsosc MariaDB nad MySQL.
Wybór bazy jest istotny, szczegolnie dla adminów, którzy będą tym zarządzać, programiści zapominają, że świat nie kończy się na nich.

SQLite ma wiele zastosowań ale w zasadzie wszystkie sa jednostanowiskowe.

Wybrać ale do czego?

Wiem, że MSSQL ma wersję Express, ale pominąłem ją, zakładając, że nie nadaje się do zastosowań innych, niż czysto hobbystyczne, bo ograniczenia na RAM / CPU okażą się niedopuszczalne. Może błędnie zakładałem.

Wybór bazy jest istotny, szczegolnie dla adminów, którzy będą tym zarządzać, programiści zapominają, że świat nie kończy się na nich.f

Aha, czyli wybór sprowadza się do tego, czym adminowi łatwiej będzie zarządzać? Czy z perspektywy programisty: co admin nakaże?

Wybrać ale do czego?

TO jednak ma znaczenie? Zakładałem, że różne SQLe to jak młotki różnych firm, są dokładnie analogicznymi produktami.

Zakładałem, że różne SQLe to jak młotki różnych firm, są dokładnie analogicznymi produktami - nie sa.

Musisz znac rozmiar bazy, jej przyrost / dzien, wymagania co do liczby użytkowników, czy baza ma byc transakcyjna, ile mozesz miec maks RAMu, czy chcesz miec obsługę Geo, Xml, Json, na jakim systemie ma pracowac, z jakimi technologiami ma sie interfejsowac itd.

Jak wybierasz coś, to przeważnie masz jakieś oczekiwania, wymagania, budżet i nie wybierasz produktu, który do nich wyraźnie nie pasuje.
Patrzysz jak produkt wpisuje się w wymagania/budżet i skreślasz te pozycje, które nie pasują.

Jaki samochód wybrać? Nie może być tak, że wybierasz samochód na podstawie tylko koloru (takie abstrakcyjny przykład, w którym kolor samochodu można porównać do odczuć developera wobec technologii), a masz do wyboru pomarańczowy kamaz, czarne X7 i żółtego fiata 126p. Czerwony kamaz jako Uber, hmm... nisza rynkowa ;)

Wybierasz baze, więc zapewne chcesz gromadzić dane. Skoro je gromadzisz, to pewnie zadajesz sobie masę pytań:

• Jak zapewnić bezpieczeństwo danym? Replikacja, backup.
• Wymogi prawne? Trzeba gromadzić dane o tym kto/kiedy/jak korzysta ze zgromadzonych danych (np. na potrzeby audytu) - funkcjonalność audytowania
• Kto będzie odpowiedzialny za utrzymanie? Ma odpowiednie umiejętności? Ile kosztują szkolenia?
• Kto będzie dostarczał wsparcie dla silnika bazodanowego?
• Czy silnik jest certyfikowany na serwerach które mam?
• Ile będzie kosztować rezygnacja z funkcjonalności X i zbudowanie protezy tej funkcjonalności? (Kto będzie utrzymywał protezję, jakie zaosby będą potrzebne do jej wdrożenia, .. )
• Z których wymagań mogę zregyznować?
• ...

W jaki sposób poszczególne produkty wspierają te wymagania? Ile to kosztuje? Ile będzie kosztować przestój jeśli baza padnie i trzeba będzie odtwarzać dane? Jaki będzie wpływ na reputację czy doświadczenie klientów?

Z mojego doświadczenia to poza wyborem bazy pod kątem jakichś specjalnych usprawnień jak postgis do postgressa, to właśnie kwestie administracyjne miały znaczenie. Jak firma ma AD i adminom łatwo tym zarządzać to MSSql server jest jak znalazł.
Integracja AD z MySql kiedyś przynajmniej wymagała płatnych dodatków. Postgres ma dodatki wykorzystujące LDAP ale znów to nie jest pełna integracja z AD i z tego co mi wiadomo nie wykorzystuje Kerberos ( ale mogę się mylić). Developersko teraz to wszystko wepchniesz do kontenera i backup, ilość instancji w klastrach czy fail over Cię nie interesuje.

Nie ma prostej, uniwersalnej odpowiedzi. Pytanie czego oczekujesz od takiej bazy i jaką ona ma pełnić rolę. Parę pytań pomocniczych:

• Czy jakakolwiek część logiki będzie po stronie bazy (procedury składowane, wyzwalacze...)
• Czy czy potrzebujesz jakiej specjalnej funkcji w tej bazie (GIS, OLAP....)
• Czy system który budujesz, będzie miał wyłączny dostęp do bazy danych
• Jak chcesz zarządzać uprawnieniami
• Czy potrzebujesz replikacji danych
• Gdzie przewidujesz deploy bazy - Windows, Linux, chmura (jaka), VM, on-premise, bare metal...
• Ile jednoczesnych transakcji przewidujesz
• Jakie wsparcie jest oczekiwane ze strony producenta
• Jakie masz doświadczenie w administracji konkretną bazą danych
• ile kosztują licencje

Wybij sobie z głowy myślenie, że baza X to Java, a Y to C#. Już się dawno tak nie pisze oprogramowania, żeby jakieś formularze ściśle integrować z bazą danych (kojarzę coś takiego jak Oracle Forms). Żeby korzystać z bazy danych wystarczy, że istnieje odpowiedni connector do bazy danych, a dla takich języków jak Java, C#, PHP istnieją raczej wszystkie możliwe connectory, więc możesz użyć dowolnej bazy danych i realnie nie ma to żadnego znaczenia.

Ogólnie MSSQL i Oracle to typowe korpo technologie do przepalania pieniędzy i czasu programistów. Jak jesteś korpo to ich używasz zawsze i wszędzie. Management będzie zadowolony, każdy inny pracownik już mniej, ale to przecież nie szkodzi. Oczywiście są jakieś bardzo specyficzne powody dla których warto je wybrać, ale na pewno nie powinny być domyślnym wyborem.

MySQL ma trochę złą sławę, ale jest to przyjemna baza danych.

MariaDB / MySQL: [...] Czemu wszyscy tego używają?

Prawdopodobnie dlatego, że kiedyś wszystkie CMSy(tym samym większość internetu) były oparte o MySQL.

Wybierz sobie :)
https://db-engines.com/en/ranking

To jak tak dodam jeszcze jedną rzecz, która może ułatwić podjęcie decyzji. Jak wyżej pisali koledzy - wybór bazy zależy w dużej mierze od okoliczności oraz jej zastosowania.

Jeśli potrzebujesz zrobić jakiegoś REST'a to rzuć okiem na https://postgrest.org/en/stable/ - "nakładka" na Postgresa, która jakby integruje bazę z serwerem REST. W sensie - nie musisz mieć osobnych dwóch rzeczy, które ze sobą gadają i potem wystawiają endpointy w świat (np. Apache, który jest serwerem REST'a i który się komunikuje przez Twoje skrypty z SQL'em), bo tutaj masz to w jednej całości.

PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations. Using PostgREST is an alternative to manual CRUD programming. Custom API servers suffer problems. Writing business logic often duplicates, ignores or hobbles database structure. Object-relational mapping is a leaky abstraction leading to slow imperative code. The PostgREST philosophy establishes a single declarative source of truth: the data itself

Jeżeli będziesz miał do dyspozycji serwer dedykowany to bierz PostgreSQL-a. Gdyby projekt miał być uruchamiany na hostingu współdzielonym to MySQL.

Moim zdaniem to cała ta dyskusja jest bez sensu. W większych projektach silnik bazy danych jest narzucony przez to co posiada już klient (nawet nie chodzi o sam program, ale administratorów z doświadczeniem) lub ze względu na koszty wybiera się rozwiązania darmowe typu PostgreSQL (w przypadku zamówień publicznych koszt projektu jest ważniejszy od wydajności, a nawet zdrowego rozsądku).

@cw: ale nie wszyscy siedzą w wielkich projektach tworzonych przez setki ludzików i wartych miliony złotych. Czasem firma 2-3 osobowa musi coś zaproponować swojemu klientowi. Albo nawet w dużych firmach - ktoś jest tym kimś, kto narzuca rozwiązanie, więc nie zgadzam się - ta dyskusja ma baaardzo dużo sensu. Co nie zmienia faktu, że najlepsza z możliwych odpowiedzi to "to zależy od okoliczności i wymagań".

Skoro MySQL nie jest marny, to skąd się wziął mit o jego marności?

Skoro Postgres nie jest super-duper, to skąd się wziął mit o jego super-duperowatości?

YetAnohterone napisał(a):

Skoro MySQL nie jest marny, to skąd się wziął mit o jego marności?

Skoro Postgres nie jest super-duper, to skąd się wziął mit o jego super-duperowatości?

Skoro szczepionki nie powodują autyzmu to skąd wziął się mit o szkodliwości szczepionek? Z powtarzanych bez refleksji obiegowych opinii.

Edit. I co do negatywnych opinii to jest jeszcze jedna przyczyną - ludzie hejtują niektóre technologie, mimo że nigdy nie mieli z nimi do czynienia, bo to jest fajne. z tego powodu hejt leci na PHP, JS, Windows, .NET czy na MySQL. Hejt nie musi mieć żadnych racjonalnych podstaw.

Wśród najpopularniejszych baz nie ma czegoś takiego jak najlepsza baza. To wszystko zależy od tego co chcesz robić, dlatego ta cała dyskusja jest bez sensu bo nie wiadomo o co Ci chodzi. Do jednych zastosowań MySQL będzie lepszy, do innych PostgreSQL, a w jeszcze innej sytuacji DB2, Firebird albo SQLite.

Nie pracowałem za wiele z Oracle, także moje drzewko decyzyjne wygląda tak:
MSSQL - pierwszy wybór, jeśli tylko budżet pozwala,
PostgreSQL - jedynie wtedy gdy brak budżetu, albo potrzebujemy jakiś bardzo specyficznych indeksów których brak w MSSQL,
MySQL - nigdy więcej
SQLite - jak nie potrzebujemy współbieżności

MsSql to jest odpowiednik windowsa w świecie baz danych, pomyślany jak dla idiotów, wiele rzeczy zautomatyzowanych, profilowanie zapytania bajka.
Postgresql to jest odpowiednik Linuksa sprzed 20 lat, niby takie same możliwości jak windows, ale żeby osiągnąć podobne rezultaty jak na MsSql to trzeba się napocić i posiadać dogłębną wiedze o specyficznych rzeczach dla tego silnika.

neves napisał(a):

Postgresql to jest odpowiednik Linuksa sprzed 20 lat, niby takie same możliwości jak windows, ale żeby osiągnąć podobne rezultaty jak na MsSql to trzeba się napocić i posiadać dogłębną wiedze o specyficznych rzeczach dla tego silnika.

Instalacja postgresa jest prosta - zarówno na windowsie jak i linuksie.

Tuning / optymalizacja / konfiguracja to też nic trudnego dla kogoś kto ma podstawowe pojęcie na podstawie wiki, 10-20 minut spokojnej pracy: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server, nawet bez tej optymalizacji podstawowe ustawienia dadzą radę do większości zastosowań.

Pewnie w dużej mierze jak kogoś zapytasz o wybór jakiejś bazy to ci powiedzą, że ta, co oni wybrali jest najlepsza, bo oni innej nie znają, a nie dlatego, że rzeczywiście jest najlepsza. Bo tak naprawdę każde to rozwiązanie ma swoje plusy dodanie i ujemne.
Z mojej prospekty (pracowałem ze wszystkimi tymi bazami przy więcej niż jednym projekcie) .
Oracel - ma sens jak nie masz naprawdę duży projekt i ludzi do oganiania. Ostatnimi czasy koszty licencji wywaliło w kosmos jak ceny paliwa. Fajne narzędzie takie jak APEX - świetny w małych i średnich projektach, bardzo dobrze rozwinięty PL/SQL. Jest masę sofrtu napisane w PL/SQLu i jeszcze przez wiele lat będzie co robić.
MSSQL - jego wadą jest przede wszystkim cena i skomplikowany system licencyjny. Bardzo dobrze działa. T-SQL ma kilka fajnych modyfikacji względem standardu. Dobre wsparcie. Od kilku lat jest też wersja dla Linuxa. Fajne narzędzia jak SSRS, SSIS itp. Jak ktoś działa w światku widowswoym to pewnie jest to dla niego pierwszy wybór.
Postgres - dobre rozwiązanie, darmowe. Poziom wsparcia porównywalny z MSSQL i można nabyć wsparcie. ma kilka denerwujących rzeczy. Ale myślę, że jest bardzo blisko MSSQL. Niestety ten cały PgAdmin jest lata świetlne za SSMS.
MySQL (i inne odłamy tego kościoła) - osobiście nie lubię przez zmieszanie z tymi silnikami. Zaliczyłem parę wpadek w zapytaniach analitycznych na tej bazie. Okazało się, że MySQL robi to jakoś inaczej niż cały świat i zapytanie trwało 2h zamiast 1s. Dobre pod bloga może pod prosty sklep.
SQLLite - tu to chyba tylko da się trzymać konfigurację albo jakieś dane podręczne. Wypierane przez konkretne implementacje w językach i platformach.

Poza samom funkcjonalnością warto spojrzeć też na to, kto to będzie utrzymywał i jak już mają 5 baz SQL Server to nie pakować im postgresa.

SQLite - jak nie potrzebujemy współbieżności

Plus jak jeszcze nie trzeba bardziej zaawansowanych ficzerów jak konta z przypisanymi uprawnieniami, replikacja, jakieś zwiększone bezpieczeństwo, nie korzystasz z RIGHT OUTER JOIN lub FULL OUTER JOIN, jeśli dużo zapisujesz to SQLite ma znacząco gorszą wydajność, SQLite ma gorsze/biedniejsze wsparcie dla triggerów, coś mi świta że bywają jakieś Unicode'owe problemy, ALTER jest wykastrowany/ograniczony, .

I żeby była jasność - uważam, że SQLite jest genialnym rozwiązaniem, tylko trzeba wiedzieć gdzie i jak z tej bazy korzystać. Brak (a właściwie - jest, ale słaba) współbieżność to tylko jedna z rzeczy, którą trzeba wziąć pod uwagę podczas podejmowania decyzji.

Instalacja postgresa jest prosta - zarówno na windowsie jak i linuksie.

Podpisuję się pod tym wszystkimi 4 łapkami. Jeśli kogoś to przerasta, to raczej powinien zmienić branżę :P (z zastrzeżeniem, że chodzi po prostu o postawienie bazy. Jej dopieszczenie i zaawansowana konfiguracja to zadanie dla osoby baardzo doświadczonej i z ogromną wiedzą/znajomością Postgresa)

żeby osiągnąć podobne rezultaty jak na MsSql to trzeba się napocić i posiadać dogłębną wiedze o specyficznych rzeczach dla tego silnika.

¿Que? PostgreSQL o ile pamiętam to DB, która jest najbliżej standardu z dostępnych i raczej unika własnych rozszerzeń, a jak coś to są one wyraźnie w dokumentacji zaznaczone. Większość rzeczy działa OotB i nie potrzebujesz Query Hints czy innych wynalazków. MS SQL w tej kwestii miał AFAIK zawsze bardziej liberalne podejście.

hauleth napisał(a):

Query Hints

Co masz na myśli?

hauleth napisał(a):

żeby osiągnąć podobne rezultaty jak na MsSql to trzeba się napocić i posiadać dogłębną wiedze o specyficznych rzeczach dla tego silnika.

¿Que? PostgreSQL o ile pamiętam to DB, która jest najbliżej standardu z dostępnych i raczej unika własnych rozszerzeń, a jak coś to są one wyraźnie w dokumentacji zaznaczone. Większość rzeczy działa OotB i nie potrzebujesz Query Hints czy innych wynalazków. MS SQL w tej kwestii miał AFAIK zawsze bardziej liberalne podejście.

Zgadza się, Postgres ma najabliższą standardów implemetancje SQL (a MySql pewnie najmniej). Tyle że bazy danych to już od dawien dawna nie sam SQL tylko masa najróżniejszych ficzerów i toolingów ułatwiajacych życie. I mój komentarz odnosił się do bazy danych jako całości, a nie tylko samego SQL'a. Tutaj pisałem zresztą o różnicach między
Postgres vs. SQL Server

YetAnohterone napisał(a):

• MSSQL: Jak się robi coś w dotnecie? Oprócz tego płatna, sensowna ale nieco gorsza alternatywa Postgresa?
• OracleDB: Jak MSSQL, tylko do Javy

W czym MSSQL jest gorszy od Postgresa?
Wydaje mi się, że do wielu zastosowań Postgres może być lepszy (chociażby z uwagi na cenę), to są ficzery, których ta baza nie ma.

Widziałem też zarówno projekty dotnetowe z Oraclem jak i Javowe z MSSQL, więc ten podział nie jest prawdziwy.

PostgreSQL ma sporo rozszerzeń - ale to jego plus (bo są opcjonalne - nie chcesz to nie dodajesz).
PostgreSQL most useful extensions

Poza tym chyba najlepiej na rynku udaje Oracla:

• EDB Postgres
• Oracle_to_Postgres_Conversion
• plpgsql-overview

A z kompatybilnością ze standardami to się zgodzę, w tej bazie jest najmniej momentów "a-ha!".

Na pewno nie Oracle.

Dzień dobry

To ja podłączę się do tematu.

Jestem na początku drogi do zrobienia swojego pierwszego projektu. Nie chcę zdradzać szczegółów, ale plan jest prosty:

• strona internetowa będąca jednocześnie wyszukiwarką pozwalającą na identyfikacji produktu przez wzgląd na jego cechy: wygląd, kształt kolor, długość, średnica
• zakładam, że będzie ona zawierać początkowo około 5000 rekordów w tabeli, w której będzie nazwa produktu
• nie chciałbym, żeby ktoś w łatwy sposób mógł skopiować dane z mojej bazy danych
• zakładam, że ilość zapytań będzie mała, bo na forum branżowym takie pytania są raz na tydzień
• konstrukcja ma być prosta więc raczej będę szedł dalej w swojej nauce do PHP tj. o ile to możliwe nie korzystać z JS, tylko taki prosty schemat no chyba, że JS będzie już koniecznym wymogiem wtedy będę zacznę się go uczyć
• oczywiście open source, bo nie jestem korporacją tylko zwykłym śmiertelnikiem
• zależy mi na wydajności i żeby sam DBMS nie był "obciążający" dla strony
• ogólnie wszystko ma być proste i TOPORNE, szybkie i wydajne ;)
• administrować i dodawać nowe rekordy będę... Ja, a znam tylko STANDARD SQL
• za wzór raczej stawiałbym sobie: https://ekrs.ms.gov.pl/web/wyszukiwarka-krs/strona-glowna/index.html
• -chodzi o to, żeby wyszukać coś z mniejszą dokładnością (kilka wyników wyszukiwania) i każdy dodatkowy parametr zmniejszał nam obszar wyszukiwania

I tu pojawia się kolejny problem. Chodzi o zdjęcia oraz pliki zawierające grafikę. Coś takiego chciałbym wprowadzić. Tutaj pytanie. Czy to już nie będzie raczej NoSQL?
No chyba, że zrobię kolumnę zawierającą odnośnik do zdjęcia, przy zidentyfikowanym przedmiocie. Będzie to mniej wygodne dla użytkownika, ale na chwilę obecną z kursów i książek nie wyczytałem, czy można umieścić obiekt w rekordzie, raczej kojarzy mi się to z NoSQL.

O ile projekt konceptualny mam, to chciałbym to raczej oprzeć o HTML/CSS, PHP i SQL (no chyba, że dałoby zamienić PHP na Python w jakiś sposób). Intuicyjnie pierwszy wybór padł na MySQL gdyż raczej nie będę potrzebował bajerów z Postgresa.

Wszystko robię "po godzinach" raczej w formie hobbystycznej oraz takiej pozytywistyczno-altruistycznej.

Pozdrawiam i jak zawsze z góry dziękuję za każde okruchy wiedzy oraz wskazówki.