Co to jest noSQL?

Ostatnio mialem aplikacje w ktorej baza danych tabelki byly na zasadzie ze
Tabela 1 zamowienie

Tabela 2 szczegoly
id | id_zamowienia | name | value
---------------- | -------------------
1 | 2 | data | 2018-03-04
2 | 2 | user | id_user
3 | 2 | is_vat | 1
4 | 2 | kwota | 3455
5 | 1 | data | 2018-03-04
6 | 1 | user | 4
7 | 1 | is_vat | 0
8 | 1 | costam | lalaal

Czy to ma sens ? to znaczy w aplikacji jak dam pole w formualrzu nowe to ono jest dodawane automatycznie jako [name = value] wiec nie musialem dodawac do bazy pola ale taka baza szybko sie zapelnia np 100 rekordow wpisow dla jednego zamowienia. To co to za styl programowania ? czy to ma byc noSql ? czy to ma sens czy nie ?

EAV - Entity–attribute–value model

https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model#EAV_databases

To nie jest noSQL tylko rak. Imitowanie jakiejś dokumentowej bazy danych za pomocą sqla.

noSQL to słowo-klucz dla wszystkich nierelacjnych mechanizmów persystencji -> bazy grafowe, dokumentowe, event sourcing

Taki model bazy nazywa się EAV i jest wykorzystywany m.in. w Magento - umożliwia dodawanie nowych pól (np. atrybutów produktów / zamówień) bez konieczności modyfikacji bazy (dodawania / usuwania kolumn).

Jest to jak najbardziej przykład bazy relacyjnej, ponieważ - intuicyjnie - każdy wiersz ma taką samą strukturę (a o to właśnie w bazach relacyjnych chodzi - https://pl.wikipedia.org/wiki/Model_relacyjny).

taki zapis ma sens jeśli się go z sensem używa i jest uzasadniony. Na pewno nie ma sensu do zapisu rzeczy, które mają 99% powtarzalnych danych (jak np. załączone pozycje zamówienia). Nie dość, że ciężko coś w tym znaleźć to i za prezentację takich rekordów w postaci tabelki (no bo jak byś chciał zaprezentować pozycje zamówienia inaczej) userowi trzeba się brać od d**y strony

Shalom napisał(a):

To nie jest noSQL tylko rak. Imitowanie jakiejś dokumentowej bazy danych za pomocą sqla.

noSQL to słowo-klucz dla wszystkich nierelacjnych mechanizmów persystencji -> bazy grafowe, dokumentowe, event sourcing

Dodam, słowo tak szerokie, że bliższe technicznemu marketingowi niż ścisłości. BTW Dało by się podać jeszcze kilka rodzajów

no wlasnie widzialem to w laravel przy uzyciu ORM to ulatwialoby sprawe gdyby system byl tworzony jak word press ale dla wewnetrznej aplikacji wiecej utrudnia niz pomaga bo dla 1 zamowienia jest ponad 100 rekordow a zamowienia sa duplikowane dla bezpieczenstwa wiec jest ich ponad 200 dla 2 wpisow. A byly lamenty ze po 2 latach program spowolnil ze nie da sie go uzywac prawie.

zamowienia sa duplikowane dla bezpieczenstwa

Daaamn :D

byly lamenty ze po 2 latach program spowolnil ze nie da sie go uzywac prawie.

Załóż odpowiednie indeksy, podrasuj serwer bazy danych i powinno śmigać jeszcze kilka lat, jeśli nie chcesz przebudowywać całej aplikacji.

Model EAV jest super, jesli np masz wiele kolumn które są nieobowiązkowe oraz w przypadku gdy często dodajesz parametry do zamówienia. Dla zamówień wydaje mi się to być kompletnie bez sensu, lepiej dorzucić po prostu kolumny. W przypadku produktów to bardzo fajne rozwiązanie. Tak jak napisał @Patryk27 rozwiązanie to występuje w magento i mogę powiedzieć że w praktyce super się to sprawdza.

Patryk27 napisał(a):

Załóż odpowiednie indeksy, podrasuj serwer bazy danych i powinno śmigać jeszcze kilka lat, jeśli nie chcesz przebudowywać całej aplikacji.

może niekoniecznie się to sprawdzić :p

EAVsprawdza się doskonale jako rozszerzenie do tabeli, tzn. masz "normalną" tabelę ze stałymi kolumnami i tabelę EAV, gdzie trzymane są "różne" kolumny do tabeli

Shalom napisał(a):

noSQL to słowo-klucz dla wszystkich nierelacjnych mechanizmów persystencji -> bazy grafowe, dokumentowe, event sourcing

Event sourcing to akurat nie jest mechanizm perzystencji tylko wzorzec, równie dobrze można przechowywać eventy w bazie relacyjnej.