Sql vs NoSql?

Question

Co według was jest bardziej przyszłościowe?
Pisze w c# i w większości przypadków, operacje wykonuje na kolekcjach, które bez żadnych problemów moge przerzucać na JSON i w drugą strone

NoSql pozwala mi po prostu zapisywać i wczytywać kolekcje z bazy - bezpieczniejsza opcja niż trzymanie wszystkiego jedynie w pamięci

W klasycznej bazie Sql musiałbym tworzyć tabele w oparciu o obiekty z których korzystam

Czy w takiej sytuacji użycie klasycznego Sql ma jakiś sens, skoro bazy danych używam tylko do przechowywania kolekcji, które normalnie siedzą w pamięci?

Może pytanie na poziomie początkującego, ale w kwestii baz danych jakoś bardzo się nie zagłębiałem. A teraz po ogarnięciu jak prosta i przyjazna jest NoSql, zastanawiam się czy Sql ma w ogóle jakiś sens? Poza utrzymywaniem projektów które były tworzone pod bazy Sql

Wiem że temat kontrowersyjny i pewnie wywołam niezłą burzę, ale z punktu osoby która baz danych używała głównie do zwykłego trzymania danych, nie widze przewagi sztywnego sql z tabelami, nad nosql - gdzie moge trzymać dane tak, jak w pamięci

Answer 1

Ze swojego doświadczenia powiem, że najczęściej pracuję z bazą MySQL w połączeniu z node, ale to nie ma teraz znaczenia. Dane trzymam w odpowiednio zaprojektowanych tabelach, ale bardzo intensywnie korzystam też z widoków, co ułatwia mi pobieranie danych w back-endzie aplikacji i pozwala nawet na pewne modyfikacje w samej strukturze bazy bez wpływu na back-end.

Bazy noSQL są fajne, ale jeśli nie zależy Ci na mocnych powiązaniach między tabelami czyli relacjach. Na przykład powiem Ci, że nie wyobrażam sobie pisać choćby systemu CRM bez dobrodziejstwa relacyjności. Co więcej np. baza MySQL pozwala na wykonanie dodatkowych zabezpieczeń chociażby przed przypadkową próbą usunięcia rekordów, które są powiązane z innymi.

Bazy noSQL są jednak bardzo fajne tak jak piszesz, w przypadku prostych kolekcji. Ale pod pojęciem prostych mam na myśli brak relacyjności, a nie prostą strukturę danych (bo ta akurat może być złożona).

Wszystko zatem jak widać do różnych zastosowań. Na przykład nie chciałbym pisać aplikacji księgowej/fakturującej bez bazy relacyjnej ale to moje subiektywne zdanie.

Nie wypowiem się też co do wydajności na dużej ilości danych. MySQL jest bardzo fajną bazą, ale trzeba dobrze zaprojektować jej strukturę, indekacje itp. aby faktycznie działała szybko przy dużym obciążeniu. Nie mniej jednak w większości prostych projektów np. dla małych firm myślę, że kwestia różnic w wydajności nie będzie najistotniejszym argumentem.

Answer 2

To zależy, czy musisz trzymać tylko dane, czy też musisz mieć również informacje o zależnościach pomiędzy nimi (np. jakie samochody należą do którego producenta). W tym pierwszym przypadku faktycznie NoSQL będzie lepszym wyborem. W tym drugim – SQL.

Niemniej jeśli chodzi o cache, to oprócz NoSQL jest też opcja np. tabel MEMORY z MySQL, co pozwala nam połączyć szybkość pamięci z formalnością SQL.

Comments

Z tym silnikiem MEMORY to bym uważał, szczególnie jeśli Kolega zaczyna przygodę z bazami danych. Na przykład jednym z ograniczeń jest brak możliwości wprowadzenia do tabeli na silniku MEMORY pól o zmiennej wartości, czyli np. pola TEXT (chociaż dopuszczalne jest VARCHAR ale to z powodu pewnych wewnętrznych sposobów interpretowania tego jako CHAR). Trzeba też uważać na pewne aspekty podczas operacji porównujących indeksy, ale to w tej chwili mało ważne.

---

Tak, ale też trzeba przyznać, że do "normalnych" zastosowań MEMORY się nie używa ;)