ovako da krenemo ispocetka
Citat:
koliko se gubi na performansama
koliko oces, ako hoces performanse nemoj da koristis JSON (vazi za svaki rdbms ukljucujuci mysql)
Citat:
binary format koji je optimizovan za operacije nad podacima ali se opet postavlja pitanje, da li je to isto ili lošije, i koliko, u odnosu na pravu tabelu
format je takav da moze lakse da se parsira json drvo nista drugo, i dalje moras da radis full table scan
Citat:
Koliko se sa JSON formatom dobija na praktičnoj strani time što bi bilo manje tabela i jednostavniji upis u bazu, a koliko se gubi kod kasnijeg izveštavanja i filtriranja podataka?
ne dobija se nista vezano za jednostavniji upis u bazu a gubi se uzasno mnogo na performansama kada pricamo o tome da je sa druge strana "validna aplikacija", kada sa druge strane imas polutadiran javascrip klijent kome je relativno svejedno onda dobijas na upisu a reporte svejedno ne radis na takvom klijentu pa je za citanje nebitno
Citat:
Ako bas oces JSON onda MongoDB
ne resava ni mongo te probleme
Citat:
Znaci overhead je prilicno veliki ako treba da dekodiras json pa onda vrsis upit,
nesto je manji overhead nego za varchar + imas funkcije koje sluze za manipulaciju json-om ali generalno da, json ne sluzi da radis upit po njemu
Citat:
Podaci koji stoje unutar JSON kolone ne mogu da imaju foreign ključ! Znači nije ih moguće vezati relacijom za neki drugi podatak. Tako ispada da se u to polje može upisati "šta hoćeš" i nema načina sa MySQL server prilikom inserta radi proveru. Ako bih, po mojoj teoriji, unutar JSON-a držao stavke nekog dokumenta, svaka stavka bi imala recimo ID artikla koji ne bi bio ni u kakvoj vezi sa tabelom artikala. I to je baš bezveze.
Čudi me da se ni u novoj verziji MySQL-a nisu bolje potrudili pa da ovo podrže. Ovako taj JSON može da se koristi samo za neke manje bitne stvari, što kaže Branimir, više kao neka napomena nego mesto gde stoje ozbiljni podaci. Baš šteta jer mislim da taj koncept ima perspektivu.
pa vidi, to je poenta json-a ... nemas strukturu, mozes da upises STA OCES u to polje, kako ocekujes foreign key iz polja koje nema strukturu u koje mozes da upises sta oces?
id artikla upises u normalno polje u istoj tabeli
nema sta to "bolje da se podrzi", gde si video foreign key sa podatkom koji je mozda tu a mozda nije
ako pogledas neke nosql-ove koji to kanda podrzavaju videces da moras da definises da to polje postoji a oni ga cuvaju kao posebno polje (i indexiraju) kao rdbms, znaci ako vec znas da uvek moras da ga imas onda ga upisi po tipu i imenu u red kao regularno polje a ne kao deo jsona
Citat:
Da, to je jasno, samo je pitanje što se nisu malo potrudili pa da celu stvar malo podinu na veći nivo. Koliko mi je poznato, davno sam gledao, MongoDB ima relacije za unutar JSON objekata. Ne vidim šta je ovima iz MySQL tima bio problem da dozvole definisanje ključeva nad poljima unutar JSON-a
pa podigli smo za red velicine u odnosu na sve ostale + je funkcionalnost bliza standardu sada nego i na svim ostalim nosql bazama, mi implementiramo vise standarda nego bilo ko drugi trenutno (ne, da je to nesto preterano bitno ali ako pricamo o "Vecem nivou", u odnosu na minimalnu podrsku do podrske koja je bliza full standardu od svih ostalih je veliki korak).
to sto neki nosql daje mogucnost da definises obavezna polja u jsonu te pravi index nad njima je njihov dodatak za relacione podatke, mi vec imamo relacione podatke te se ocekuje da te polje upises u relacioni deo tabele.. teoretski mi bi mogli da dodamo vidljiva ili hidden polja koja bi ti kreirao sa extended create gde bi rekao u mom json-u mora bude polje x,y,z koje je u relaciji ovako ... i onda kad radis insert u json mi auto da parsiramo to i da popunimo ta polja .. no sto bi to radili kada je to mnogo jednostavnije uraditi na klijentu, najcesce i brze uraditi na klijentu (ti na klijentu vec tacno imas te vrednosti ne mora ih parsiras) pri insertu gde se daje mnogo veca sloboda na taj nacin .. svaki drugi nacin bi samo nepotrebno komplikovao stvari ... a ako oces sa klijenta automatski, ti uvek mozes da napises stored proceduru za insert koja ce ti popuniti auto ta polja iz jsona u relaciona polja, ili trigger ili ...
Citat:
MySQL ekipa svojevremeno nije htela da prihvati neke mnogo važnije koncepte pa je na kraju ipak legla na rudu.
ne mysql ekipa nego Monti, on je covek bio protiv relacija, protiv innodb-a, protiv subselecta, protiv right joina, protiv materialized tabela, protiv testiranja, protiv open source-a i tako dalje i tako dalje .. ekipa kao ekipa je uvek za sto vise fancy opcija i mogucnosti i kako je Monti otisao doticne se dodaju nekim redom i brzinom koja je moguca sa kolicinom ljudstva koje imamo..