[michal__q]

Dobrze rozumiem że baza NoSQL pozbywa się całkiem relacji, więc wiele danych w niej jest po prostu dublowana?
Załóżmy bazę z dwoma tabelami, autorzy i książki, tabela autorzy zawiera autorów: imię, nazwisko, rok urodzenia, skąd pochodzą, narodowość i masę innych rzeczy a książki to tytuł, gatunek, ilość stron itd...
W podejściu relacyjnej bazy w książkach mielibyśmy id do autora taki zwykły integer.
W podejściu NoSQL do x książek tego samego autora przypisywane jest x razy te same dane dotyczące autora.
Teraz autor Y umiera i aktualizujemy informację o nim:
w relacyjnej bazie zmieniamy 1 rekord,
w bazie nosql zmieniamy x rekordów, wszędzie tam, gdzie występuje wzmianka o autorze?
Dobrze to rozumiem?

#nosql #sql #rdbms #database #databases #bazydanych

[G.....n]

@michal__q: Niby tak, ale to jest złe podejście - duplikowane dane powinny być możliwie niezmienne.
Innym rozwiązaniem są relacje, np. tak rozwiązane: http://docs.mongodb.org/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/

[michal__q]

@Ginden: No tak, myślę trochę pod sql, gdzie do książek dopisuje się autora, w nosqlowym rozwiązaniu to jest bardziej naturalne i do autora przypisuje się książki, w takim wypadku to ma sens i dane się nie dublują w rozwiązaniu

[ 
 {autor: [
 {książka1},
 {książka2}
 ],
 {autor2: {...},...}...]

Tylko pozostaje jeszcze jedna rzesz; oczywiście, daje nam to pewną szybkość odczytu jeśli chcemy wyciągać dane według autorów, ale jeśli autorzy nas nie interesują

[bziuuumor]

@michal__q: zależy jaka NoSQL. NoSQL to tylko nazwa nurtu, jest kilka rodzajów baz i "struktur danych". Np. grafowa baza danych da Ci dużo lepszą wydajność na danych które przedstawiają relację, bo naturalnie je odzwierciedla (w przeciwieństwie do relacyjnych baz danych ;) ). Na grafie od jednego autora (węzeł grafu) masz x relacji do książek które napisał. W przypadku wspomnianej śmierci autora również zmieniasz tylko info w węźle autora, nie musisz nic