Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

JSON tip podataka

[es] :: MySQL :: JSON tip podataka

Strane: 1 2

[ Pregleda: 6032 | Odgovora: 27 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon JSON tip podataka14.05.2018. u 02:36 - pre 71 meseci
U poslednje vreme JSON tip podataka postaje aktuelan, u MySQL 8 se najavljuju brojna poboljšanja ali i dalje imam nedoumice koliko se gubi na performansama ako bi se koristilo.

Evo recimo da pogledamo sledeći primer. Ako želimo da snimamo neka dokumenta u bazu, standardno bi koristili dve tabele. U jednoj bi bila sama dokumenta a u drugoj stavke. Kad se dokument snima, u transakciji se upiše sam dokument i zatim slede inserti za tabelu stavki. Ako bi koristili PHP i prepared statements, tu bi imali gomilu transakcija ka bazi, praktično onoliko koliko ima stavki + dokument.

Sa druge strane, ako bi stavke spakovao u JSON, onda bi imao jednu tabelu i jedan upis u bazu. Znači, bila bi tabela dokumenata gde bi jedna kolona bila "stavke" i tu bi bio JSON sa stavkama. Brzina upisa bi definitivno bila bolja jer bi bila jedna transakcija ka bazi i upis u jednu tabelu. Naime, JSON sa stavkama već imam od strane client forme koji se, posle validacije, samo prosledi bazi. U tom kontekstu mi se čini da bi brzina upisa (pa čak i izmena) dokumenata bila značajno poboljšana nego u prethodnom "old fashioned" načinu sa dve tabele.

E sad dolazi ono što me brine. Koliki je gubitak na performansama kad bi se radile "vertikalne" analize nad tako unetim JSON stavkama? Na primer, svaka stavka ima id artikla, količinu, cenu, koješta... i sad hoću da dobijem spisak najprodavanijih artikala sa njihovim vrednostima. U slučaju one prve varijante, imao bih tabelu koja se lako filtrira dok u ovom drugom slučaju MySQL mora da prolazi kroz JSON podatke što je, pretpostavljam, procesorski zahtevnije. Naravno, oni kažu kako ti JSON podaci ne stoje baš u text obliku kako ih mi ljudi vidimo već da se to pretvara u 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.

Na netu nema nešto mnogo testova koji razjašnjavaju ovu dilemu, pogotovo za MySQL 8 pa me zanima šta mislite? 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?

 
Odgovor na temu

svepomalo

Član broj: 306404
Poruke: 196



+21 Profil

icon Re: JSON tip podataka14.05.2018. u 02:49 - pre 71 meseci
Mslim da ne valja jos uvek.
Ako bas oces JSON onda MongoDB
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
178.250.138.210



+1064 Profil

icon Re: JSON tip podataka14.05.2018. u 03:05 - pre 71 meseci
mysql podrzava insert sa vise vrednosti tako da sve mozes stavke uneti sa istim. JSON pakujes samo onda kada neces praviti nikakav upit po stavkama. Zamisli zapravo da stavis u varchar polje ceo json, to ti je to. Znaci overhead je prilicno veliki ako treba da dekodiras json pa onda vrsis upit,
i to bi radilo sporo.
 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: JSON tip podataka14.05.2018. u 07:23 - pre 71 meseci
Ima tu još jedan problem, i to veoma gadan :)

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.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: JSON tip podataka14.05.2018. u 08:37 - pre 71 meseci
noSQL (JSON) format je pogodan za podatke koji nisu relacione prirode i urpavo su takve strukture. Ne valja relacione podatke prebacivati u noSQL jer se onda gube sve pogodnosti relacionog modela.

Nije to pitanje ili-ili nego korsititi onakvu strukturu koja odgovara prirodi podataka sa kojima se radi.

 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: JSON tip podataka14.05.2018. u 09:03 - pre 71 meseci
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. Tako bih mogao da postavim da JSON key "artikal_id" bude foreign key i da se vezuje za tabelu artikala. I sada MySQL ima validaciju inputa JSON stringa stim što se proverava sintaksa a u ovom slučaju bi se proveravao i dotični ključ. Prosto mi je neverovatno da ovako nešto banalno nisu mogli da naprave. Dobili bi moćnu bazu gde bi korisnici mogli da imaju "mešoviti" model rada sa bazom, SQL i NoSQL, što sada nemaju ni MySQL i MongoDB.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: JSON tip podataka14.05.2018. u 09:12 - pre 71 meseci
Verovatno ce vremenom napraviti. MySQL ekipa svojevremeno nije htela da prihvati neke mnogo važnije koncepte pa je na kraju ipak legla na rudu.

Nisam nešto mnogo radio sa noSQL pa verovtno i ne razumem sve to najbolje, ali sam malo gledao kao to MongoDB radi jer smo radili jedan projekat koristeći ga i imam utisak da to što on radi je u stvari silovanje. Prosto nQSL struktura nije pogodna za neke stvari. Neki koncepri su po prirodi relacioni i da bi to radili optimalno i podaci treba da budu relacioni,
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2377 Profil

icon Re: JSON tip podataka14.05.2018. u 11:02 - pre 71 meseci
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..


 
Odgovor na temu

anon334571

Član broj: 334571
Poruke: 228
*.dynamic.vipmobile.rs.



+37 Profil

icon Re: JSON tip podataka14.05.2018. u 15:55 - pre 71 meseci
Namera JSON nije da cuvas podatke, vec da ga koristis kao externi interfejs. A ako dobro definises json, nema usporenja. To je sa ciljem da ne bi externim izvorima morao da omogucavas pristup bazi, vec samo api json.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: JSON tip podataka14.05.2018. u 16:11 - pre 71 meseci
json api je razlicit od json tipe podataka (mislim da je op explicitno
mislio na tip podataka obzirom na ime teme :D )... sto se json api-a
tice mysql trenutno od svih sql servera ima najjacu podrsku, overhead je
nikakav, radi 1/1 ... i za razliku od json tipa, json api je prilicno
korisna stvar :D
 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: JSON tip podataka15.05.2018. u 10:52 - pre 71 meseci
Citat:
bogdan.kecman:
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 ...


Da, upravo sam na ovo mislio. Prenost JSON-a je što je višedimenzionalan i što njegov ekvivalent u bazi predstavlja više tabela povezanih relacijama. Tako onda ispada da JSON koji dobijem od klijenta moram da razlažem, pretvaram u SQL komande i raspoređujem po tabelama a onda, u obrnutom smeru, da skupljam podatke po tabelama, sklapam u JSON i vraćam nazad. Zato i kažem, zar ne bi bilo logično da se i baza podataka malo "prilagodi" scenarijima realnog sveta pa da omogući nešto što bi bilo korisno? Naravno, ne smatram da ovim treba da se odustane od koncepta relacionih podataka već da se JSON podrška ponudi kao DODATAK pa onda da svako može da kombinuje sistem prema svojim potrebama.

Dakle, radilo bi tako da prilikom definisanja JSON tipa podaka, definišeš i njegove ključeve i relacije sa drugim podacima (kako prvim tabelama, tako i drugim JSON-ovima) i onda baza da vodi računa o integritetu (što joj je i posao). Naravno da to sve može na klijentu ali je besmisleno. Ako bi želeo da imam stavke fakture unutar JSON-a, malo je besmisleno da na klijent strani prvo povučem iz baze spisak ID-ova artikala, proverim JSON objekat i onda kad se uverim da je sve ok, pošaljem ga u bazu. Onda šta će mi baza ;)

Ideja iza cele ove priče je da se korisnici (koji to žele naravno), manje bave modeliranjem baze već da db server to uradi za njih. Dakle ako serveru pošaljem JSON određene strukture, koji je naravno višedimenzionalan, prethodno bazi dam neke smernice (koja polja su šta i koji su ključevi), da sama baza napravi sebi interne tabele sa relacijama gde će sve to da vodi. Drugim rečima, to bi zapravio bio jedan layer gde bi se podaci i čuvali interno u nekakvim virtuelnim tabelama a korisnicima predstavljali u vidu JSON objekata.

Naravno, opet ponavljam: Poenta ovoga nije da se zamene relacione baze i modeliranje. Mislim da je to neophodno da postoji i uvek će se koristiti, već da postoji alternativa pa da imamo veći izbor. Evo napraviću malu analogiju: ako fotograf hoće da pravi vrhunske slike, koristiće manuelna podešavanja na aparatu ali opet, ako je svestan da će u određenoj situaciji automatika više nego odlično odraditi posao, siguno neće biti mazohista pa da se petlja sa podešavanjima već će koristiti auto mod.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2377 Profil

icon Re: JSON tip podataka15.05.2018. u 11:22 - pre 71 meseci
Citat:

Prenost JSON-a je što je višedimenzionalan i što njegov ekvivalent u bazi predstavlja više tabela povezanih relacijama

pa sad, "visedim.." je po meni pogresna definicija ovde, json je samo nacin/format zapisa drvenaste strukture, to je obican string, ovi razni nosql-ovi cuvaju key/value znaci ne razumeju strukturu tog drveta, tj i za njih je to obican string isto kao i za mysql ili psql ... jedini db server koji razume kako treba tu strukturu je ldap (razne verzije istog)... a najbrzi ldap na svetu je implementiran obicnom flat tabelom u ndbcluster-u ... znaci celo drvo je jedna flat tabela obicna.. mozemo da pricamo o prednostima drvene strukture u odnosu na relacionu strukturu, i jedna i druga imaju svoje prednosti, ali kada pricamo o sql i nosql serverima oni ne je123 tu drvenu strukturu 2% vec ceo taj json posmatraju kao jedan "dokument" i to je to... to je jedan string value... to sto imas par helper funkcija za parsiranje tog stringa je potpuno nebitno, i za jednu i za drugu seriju db servera to je string... svako ko misli da je drugacije ne razume kako db serveri rade

Citat:

Tako onda ispada da JSON koji dobijem od klijenta moram da razlažem, pretvaram u SQL komande i raspoređujem po tabelama a onda, u obrnutom smeru, da skupljam podatke po tabelama, sklapam u JSON i vraćam nazad.

to iz onoga sto sam ja napisao nisi mogao da shvatis ako si procitao ono sto sam ja napisao pazljivo a ne po dijagonali

Citat:

Zato i kažem, zar ne bi bilo logično da se i baza podataka malo "prilagodi" scenarijima realnog sveta pa da omogući nešto što bi bilo korisno? Naravno, ne smatram da ovim treba da se odustane od koncepta relacionih podataka već da se JSON podrška ponudi kao DODATAK pa onda da svako može da kombinuje sistem prema svojim potrebama.

o mysql-u moze se prica sta oces ali to je jedini sistem koji je baziran samo na realnim scenarijima, ono sto se koristi to je uvek bilo implementirano a filozofija, teska matematika, i koncept koji koristi 1 promil developera je uvek ostavljan za posle (sada je i vecina toga implementirano u 8.0 posto je bilo prostora)... tako da to sto ti mozda ne razumes koncept ili ga posmatras iz ugla 1 promila korisnika ne znaci da je to "realni svet" :D vec da ti ne znas kako se to u realnom svetu implementira :D

Citat:

radilo bi tako da prilikom definisanja JSON tipa podaka

nece u realnom svetu developer da definise tip i zeli da moze da ga promeni bez pipanja baze, to su "javascript developeri" koji nemaju pojma sta je to index

Citat:

i onda baza da vodi računa o integritetu (što joj je i posao)

ne mozes iz "stringa" da vodis racuna o integritetu..
cela poenta je u tome, ako imas podatak koji je relacioni cuvaj ga u relacionom delu tabele, json nije tip tabele, to je tip polja znaci ti mozes da imas
id int, id_knjige int, id_biblioteke int, metadataoknjizi json
u metadataoknjizi mozes da imas negde i polje id_knjige i id_biblioteke ali ta dva polja izvuci u tabelu i koristi kako treba, ako neces sam svaki put da radis to, kao sto ces u mongu da definises da su ta dva polja indexirana tako u mysql-u uz definiciju tabele napises i triger (i jedno i drugo radis jednom) koji ce ti na insert/update da izvadi (imas json helper funkcije) tu datu iz matadataoknjizi i upise je u id_knjige i id_biblioteke ... (potpuno istu stvar radi i mongo, ne indexira on nod u json stablu vec kopira tu vrednost u obicnu tabelu sa btree indexom u kojoj je taj "dokument" (json) jedna vrednost a svi ti indexirani nodovi po jedna ..

Citat:

Ako bi želeo da imam stavke fakture unutar JSON-a,

ako to zelis onda koristis pogresan alat i vrlo verovatno se bavis pogresnom profesijom

Citat:

manje bave modeliranjem baze već da db server to uradi za njih.

za te "korisnike" koji ne razumeju rdbms i ne umeju da modeliraju bazu i ne zele to da nauce je i napravljen mongodb, nema takav sta da trazi sa rdbms-om

Citat:

Naravno, opet ponavljam: Poenta ovoga nije da se zamene relacione baze i modeliranje. Mislim da je to neophodno da postoji i uvek će se koristiti, već da postoji alternativa pa da imamo veći izbor. Evo napraviću malu analogiju: ako fotograf hoće da pravi vrhunske slike, koristiće manuelna podešavanja na aparatu ali opet, ako je svestan da će u određenoj situaciji automatika više nego odlično odraditi posao, siguno neće biti mazohista pa da se petlja sa podešavanjima već će koristiti auto mod.


kao neko ko se 20+ godina bavi fotografijom mogu da ti kazem da ti analogija nema nikakvog smisla, tj. potpuno je pogresna.. meni, koji sam daleko od profi fotografa, aparat stoji zakucan na M (manuelni nacin rada) i odatle ne mrda, podesavanje aparata za svaku sliku traje milisekundu i potpuno je prirodno i logicno i potreba za "auto" (idiot) modom ne postoji... potpuno isto kao i kad modeliras bazu, kada znas kako se to radi ne pada ti na pamet da pustas bilo kakvu automatiku da to radi umesto tebe... nema tu nikakvog mazohizma, ili znas ili ne znas, ako ne znas onda trazis da ti sto vise posla uradi neka automatika, no to ne znaci da tako treba, nego da ne znas


 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2377 Profil

icon Re: JSON tip podataka15.05.2018. u 11:27 - pre 71 meseci
btw @saja, mislim da je jasno da ne mislim nista lose i da ne napadam nikoga... to je sve samo moje misljenje, tvoje da se slozis ili ne sa njim

 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: JSON tip podataka15.05.2018. u 11:57 - pre 71 meseci
Bogdan ti je rekao šta treba da se radi sa stanovišta nekoga ko je razvijao DB, ja kao developer mogu samo da potvrdim.
Sve što stigne spolja kao JSON, XML, SWIFT ili bilo koja druga nestrukturisana "drvenasta" struktura, čuva se u bazi samo kao dokument, log i NE PRETRAŽUJE se.
Ono od struktrurnih podataka, staviš u tabelu, definišeš indekse kako treba, a originalnu poruku čuvaš samo kroz referencu na ulazni podatak, ako tamo ima nešto što nisi "strukturisao".
Tako rade i DMS, čuvaju dokument, a u relacionoj tabeli drže ključne reči, metapodatke o dokumentu, a kada mora, ide se na full text search, ako ne postoji podatak u metapodacima.
 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: JSON tip podataka15.05.2018. u 11:59 - pre 71 meseci
Citat:
bogdan.kecman : jedini db server koji razume kako treba tu strukturu je ldap (razne verzije istog)... a najbrzi ldap na svetu je implementiran obicnom flat tabelom u ndbcluster-u

Kako izgleda ta tabela ? Znam da se npr. rdf graph cuva kao triple store.. json bi mozda isao name, value i neki pointer na parent ?
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: JSON tip podataka15.05.2018. u 12:18 - pre 71 meseci
@dejanet, izgleda uber jednostavno

f1,f2,f3,f4,f4.....fmax

i ima primary key (f1,f2,f3....fmax)

sva polja su varchar

i to jeto .. nema velike pameti

ima ogranicenje na dubinu drveta, jer nemas gde da upises nista dublje
od fmax i to je to... obzirom da se ldap najvise koristi (oni su ga i
smislili) u telekomu njima  dubina od 8 uglavnom zavrsava posao posto
oni svejedno sharduju datu .. a 8 je relativno sitna vrednost za max :D
za bilo koji rdbms

index na mysql-u ide uvek a,* pa a,b,* pa a,b,c,* etc ... tako da je
idealan za ldap upite jer ti ne pravis nikad ldap upit koji je a=x, b=y,
c=*, d=z .. vec uvek imas pocetak i trazis sve "ispod" njega tako da su
upiti bezobrazno brzi (pk upit je svaki) ... imas malo "waste of space"
ali to se do jaja komprimuje ako ti je frka za space
 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: JSON tip podataka15.05.2018. u 12:52 - pre 71 meseci
Thanks man
 
Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
*.tippnet.co.rs.



+218 Profil

icon Re: JSON tip podataka15.05.2018. u 14:18 - pre 71 meseci
Mislim da nije dobar primer kada se koristi JSON tip podataka gde imas dokument i gde imas stavke.
Meni se JSON tip podataka pokazao koristan kada npr imas formu sa dosta "on-off" elemenata pa ne moras za svaki element da pravis kolonu.
Mogu tu da se obace i ostali elementi forme samo je bitno da nema potrebe za nekom pretragom po tim elementima vec samo obicno cuvanje podatka.
Korisno mi je bilo kada sam imao neki proces koji je dobijao X poruka i onda sam te poruke cuvao u json formatu. To lici na ovo dokument-stavke ali je opet obicno citanje-pisanje i nista vise.
[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]
 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: JSON tip podataka15.05.2018. u 15:16 - pre 71 meseci
Citat:
VladaSu: Mislim da nije dobar primer kada se koristi JSON tip podataka gde imas dokument i gde imas stavke.


Da, to je i meni jasno, nažalost, i pokušao sam da pokrenem diskusiju u pravcu da se poveća vrednost tog formata ali đoka, koliko vidim, nema se mnogo razumevanja. Dok ja ovde pokušavam da "vučem ka napretku" kako bi baze "razumele" objektne podatke, ovde se cela stvar banalizuje tvrdnjom kako je to samo običan string ili dokument bez ikakvog ulaženja u suštinu objekta. Kako bez volje nema ni napretka, tako mi se čini da ćemo duže ostati na relacionim bazama o kojima inače nemam ništa protiv, samo mislim da sve to može bolje.
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: JSON tip podataka15.05.2018. u 15:59 - pre 71 meseci
Relaciona baza treba da ima jednostavan i jasan interfejs i da izvršava komande pouzdano i što brže. To dolazi u koliziju sa željom da baza bude "pametna" i da razume "objektne podatke" (btw JSON nema veze sa objektima, iako mu ime to sugeriše).
 
Odgovor na temu

[es] :: MySQL :: JSON tip podataka

Strane: 1 2

[ Pregleda: 6032 | Odgovora: 27 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.