Citat:
S A J A:
Ako u JSON kolonu ubacim string {"name":"John", "age":31, "city":"New York"}, to mu dođe ekvivalentno kao da sam u dotičnu tabelu dodao još 3 kolone, zar ne? Ovo bi database server mogao da interpretira tako što bi dodao te 3 kolone, virtuelne naravno, ali sa svim mogućnostima koje imaju i prave kolone.
....
Koja je poenta? Pa da database server ne mora JSON da shvata kao dumb string već podatke može da rasčlanjuje po tabelama i da omogući korisniku podjednake performanse za obradu kao i u slučaju klasičnih relacionih tabela.
Gledaj, to je JAKO puno heavy lifting-a, sve sa ciljem da ti ne mislis nista. Pri tom, DB je nesto sto, generalno, ne skalira sjajno horizontalno, vec uglavnom vertikalno. To sto ti zelis bi, eventualno, mogao neki ORM da ti obezbedi, a nikako baza.
Dodatno, te translacije nisu bas super-proste da se uvek upare, posebno kad u nekima fali neko polje. Sta onda? Da li praviti dve razlicite grupe tabela, ili trpati sve u iste tabele, ili hoces da svaka ide u svoju schema-u.... ? Previse je to "pameti" za upucati u bazu cak i da nije heavy lifting, a jeste.
Mogucnost da se ima document storage je ziva zgoda, jer mozes da izbacis mongo i slicne sisteme iz price, ako ti ne trebaju neke specificne varijante. Upit po json-u je i mongo-u neka olap-like varijanta koja vuce tezak full table scan i realno je i/o dependant. Ima smisla ponekad, ako mora, i samo za izvlacenje specificne date, nikako za redovan rad i updates. :)
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'