Którą bazę SQL wybrać?

1

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
  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)
2

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.

3

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

4

Wybrać ale do czego?

0

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.

4

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.

5

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?

7

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.

1

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

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