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

Polja koja mogu da budu al ne mora da znaci

[es] :: MySQL :: Polja koja mogu da budu al ne mora da znaci

Strane: 1 2

[ Pregleda: 9563 | Odgovora: 31 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Polja koja mogu da budu al ne mora da znaci14.07.2016. u 09:53 - pre 399 dana i 14h
Prije svega, izvinjavam se na ovom clickbaity naslovu :-)

Zanima best practice, ili prosto kako vi rijesavate situacije gdje recimo imate neke artikle, i oni sad imaju neke standardne kolone, koje sve uvijek imaju neke vrijednosti, ali tu i tamo neki artikal recimo ima potrebe da ima jednu dodatnu kolonu, koja bi kod vecine ostalih artikala ili bila NULL ili imala neku default vrijednost. Lupam, neki artikal ima jos dodatno uputstvo za rukovanje ili upotrebu, koje je potrebno da se dodatno naglasi i napomene.
Varijanta 1: postoji ta kolona u tabeli artikal i da stavi NULL za sve one artikle koji nemaju vrijednost
Varijanta 2: postoji ta kolona u tabeli artikal i tamo gdje nema potrebe za specificnom vrijednoscu tog polja, stoji neki default koji vazi za sve te artikle
Varijanta 3: odvojena tabela koja ima FK iz tabele artikal, zatim ima kolonu CUSTOM_VALUE u kojoj se nalazi konstanta koja opisuje tu vrijednost (jer u ovu kolonu mogu da idu i druge custom vrijednosti, recimo napomena o isteku roka trajanja) i naravno kolona value u kojoj je taj sami specificni opis
Varijanta 4: ?

Imate li neke sugestije?
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 10:07 - pre 399 dana i 14h
ja licno ili v3 ili mnogo cesce v4, v4 je - nemam uopste jednu tabelu sa
kolonama vezanim za taj artikl vec imam sistem tabela, znas i sam tu
foru, imas objekat, imas object properties, svaki property ima type, u
odnosu na type ima vrednost u odgovarajucoj tabeli .. ako pogledam ove
vece shopove kojima imam uvid u strukturu date.. svi su v4 ..
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 10:11 - pre 399 dana i 14h
Nažalost ne znam za tu foru :D
Možeš li samo malo još da je opišeš detaljnije ili da daš neki link gdje to opisano ili gdje ima neki primjer?
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 10:39 - pre 399 dana i 13h
stao mi mozak kako se zove taj model, mnogo je popularan spominjali smo
ovde na forumu bar 20 puta ... ako niko ne ucuka pre mene seticu se ja
cim se razbudim pa cu ti ucukam :D
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4352



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 11:00 - pre 399 dana i 13h
https://en.wikipedia.org/wiki/...3attribute%E2%80%93value_model (EAV) i koliko vidim vodi se kao antipattern, tj. nešto što bi u većini slučajeva trebalo izbegavati. Kao alternativa predlaže se neko od nasleđivanja, ili (b)lob polje (koje u poslednje vreme baze jako dobro hendluju). Preporučujem knjigu SQL antipatterns.

Pogledaj i ovde: http://dba.stackexchange.com/q...me-for-this-database-structure
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 11:33 - pre 399 dana i 12h
A imaš li da preporučiš neku od varijanti, ili glasaš za neku od predloženih?

edit: ok, sad gledam predloge na ovom linku...
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 11:43 - pre 399 dana i 12h
da da eav .. vidis kako ima ko ne zaboravlja te stvari :D ... ja mogu
pricam satima o njemu al kad treba se setim kako se zove stane mi mozak :(

obzirom da pricamo o okvirima mysql-a
- blob nije resenje
- json/xml i ostala bratija nisu resenje

a to da ih "dobro hendluju", hendluju ih uzasno, nego su developeri
poceli da sisaju "sve" a filtriranje rade na klijentu :(
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 11:51 - pre 399 dana i 12h
btw ovo sto ja koristim ( i sto uglavnim svi veliki koriste) je nesto
modifikovan eav, dakle nemas klasican key-value vec imas uz key i type a
onda imas po jednu tabelu za svaki type za value te onda iz ove ili one
tabele vadis value zavisno od toga koji je type .. malo komplicira
stvari ali ...

takodje svaka ozbiljnija implementacija ovde koristi SP za upisivanje
vrednosti te kroz sp radis kontrolu validnosti podataka (druga varijanta
je da je baza skroz glupa i da verujes dati koja dolazi sa klijenta, sto
nije bas moderan pristup)

e sad, kaze jablan "izbegavati" ... moras da izvagas dal ti treba ili ne
.. evo ti npr ooyyo.com ti je odlican primer, probali su eav varijantu
probali su klasicnu tabelu sa viskom kolona tj sve moguce kolone koje im
trebaju su stavili pa neki auto koristi ove a neki one .. varijanta sa
"viskom kolona" uzima oko 3x vise mesta (disk/ram) od eav varijante ali
varijanta sa viskom kolona radi za vise od red velicine brze od
varijante bez viska kolona .. tako da .. jbg .. sta ti je bitnije, da
sacuvas storage (ni ssd ni ram nisu bas jeftini) ili performanse :D ...
mobile.de na primer, ista prica .. sa druge strane bookings je eav (opet
budzen, ne klasican al eav) .. bitno ti je kako koristis podatke, sta
vadis, kad vadis, kako vadis .. ako te zanima 2-3 atributa samo za
pretragu bas te briga, sto kaze jablan turi to u blob a ta 2-3 atributa
izvuci u kolone i to je to ... web-u posaljes taj blob pa nek se smara
da ga raspakuje i prikaze kako mu volja :D ... ako radis pretragu po tim
atributima onda jbg .. zaboravi blob
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 12:19 - pre 399 dana i 12h
Polja za koja mi ovo treba su manje bitna polja, nikakva pretraga se ne radi po njima i potrebna su samo da se prikazu uz taj proizvod kad se ode na detalje tog proizvoda.

Evo kako sam ja to trenutno zamislio, mockup skracena stripovana verzija.
tabela proizvod, ima id, i naziv prozivoda i datum unosa.
tabela sve_custom_vrijednosti ima id i naziv_custom_vrijednosti u kojoj ima nekoliko vrijednosti, npr. SPECIFICNO_UPUTSTVO_ZA_RUKOVANJE, pa onda NAPOMENA_O_ZAPALJIVOSTI itd....
tabela dodatni_info_o_prozivodu ima id, ima FK iz tabele proizvod, ima FK iz tabele sve_custom_vrijednosti i ima value u koje npr. stoji "za rukovanje ovim ultra zapaljivim lakom, nemojte da prinosite otvoreni plamen" i onda bih joinovima tih tabela izvlacio ako neki prozivod ima dodatne informacije.
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 12:28 - pre 399 dana i 11h
a vidi tu ti jablanova ideja sa blob-om radi posao 1/1 zato sto ti mysql
ne trosi neko mesto u tabeli za blob polje ako je prazno psoebno ako
nemas kljuc nad blobom .. dodas blob i u njega upucas sve to sto mora
negde da imas a ne treba ti
 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1222
*.dynamic.sbb.rs.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 12:33 - pre 399 dana i 11h
Pravo je pitanje da li su ovi SPECIFICNO_UPUTSTVO_ZA_RUKOVANJE, NAPOMENA_O_ZAPALJIVOSTI, itd...
dinamički ili ne i koliko ih ima?
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 12:39 - pre 399 dana i 11h
^kako mislis da li su dinamicki ili ne?
oko njihovog broja... recimo da ima 1000 artikala, a ukupno ovih ili onih specificnih polja/opisa za sve te artikle zajedno ima mozda pedesetak
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4352



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 12:43 - pre 399 dana i 11h
Citat:
Tyler Durden:
A imaš li da preporučiš neku od varijanti, ili glasaš za neku od predloženih?

Zavisi od slučaja. Svakako ne bih koristio mysql, za početak. :)
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 12:55 - pre 399 dana i 11h
nadam se da kapiras koliko si konstruktivan :-)
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4352



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 13:09 - pre 399 dana i 11h
Dobro de. Ali pazi, u zavisnosti od zahteva, možda ima logike i da dodaš poseban key-value store za ove podatke. Inače, ne znam zašto blob ne bi bio rešenje čak i pod mysql-om. Npr. Rails od verzije 4 ima prilično dobru podršku za serijalizaciju heševa u jedno polje, na Postgresu može da koristi hstore/json, a drugde koristi standardno text polje. Znači, može i ovako i onako.
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 13:22 - pre 399 dana i 10h
kad kazete blob na sta konkretno mislite?
da dodam jos jednu kolonu u proizvod tabelu (i tako je denormalizujem) koja ce biti blob i u nju spucam sve sto sto je tako neko siroce od podatka, u nekom json ili xml formatu?
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 13:25 - pre 399 dana i 10h
sta moze da uradi u drugom rdbms-u ili key-value store-u je potpuno
nebitno za ovu temu, moze i da pise po papiricima i da koristi m$sql ili
oracle db potpuno mu isto pomaze ... mysql ne moze da radi nikakav
koristan search kroz strukturu u blobu a rails i njegova podrska za
blobove je vracanje na papirice i olovku .. dakle ako mu treba bilo
kakva pretraga po tim podacima blob je beskoristan za to u mysql-u ...
ako mu ne treba pretraga po tome onda moze da ih sacuva kako god .. u
blobu (koji sluzi bas za to) na primer..
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4352



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 13:32 - pre 399 dana i 10h
@Tyler: baš to.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

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

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 13:40 - pre 399 dana i 10h
blob, text, zavisi sta ce guras, koji format - koji je tebi zgodan ..
mysql tek od 5.7 ima neku pateticnu podrsku za json .. ako si na 5.7
mozda ti je zgodno da se igras sa tim, ako ne, uguraj sta god ti znaci
da lako zapakujes i otpakujes na klijentu ... ako je klijent neki php
serialize rulez :D
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 1906

ICQ: 49345867
Sajt: model-m.blogspot.com


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 14:37 - pre 399 dana i 9h
Cisto iz licnog iskustva: Ako je u pitanju neka tabela koja se koristi za mnogo toga ima smisla podeliti je na dve. Posto ovde deluje da ce to da se koristi ja bi, ako ne ides na EAV, isao na dve tabele:

- Artikal (ID, Sifra, Ime, Cena, Lager). Ono sto ti UVEK treba, kad radis SELECT *, jer ces cesto da radis SELECT *. Vodi racuna, kad radis SELECT ID,Sifra,Ime,Cena, a nema covering index - to je isto SELECT *. DB Engine kad cita red uvek cita CEO red iz storage engine-a. Covering index ti resava taj problem, ali prouci sta je u MySQL-u covering index, moras da poklopis i redosled.

- ArticalDetails (ID, ID_Artikla, Polje1, Polje2....). Ovo dovlacis samo kad ti treba, implicitnim ili explicitnim join-om. Ovde mozes da imas i NULL-ove, ovo nije EAV, vec samo parcanje jedne tabele na dva dela. Ako ti svi ti dodatni podaci trebaju 5% vremena, onda 95% vremena ti trosis IOPS-e diska da ih citas u prazno.... Sto je, sto moja cerka kaze, blesavo. :D Na listanju, pregledu, kupovini i proveri lagera... na svemu tome ti ne treba podatak o roku trajanja, o garanciji, o cemu vec imas te dodatne atribute....

Ako guras u serijalizovani JSON, onda samo zguras taj json u drugu tabelu. Cilj je samo da ustedis resurse i da ne citas sve to svaki put kad gledas koliko ih ima na lageru, a da ne moras da imas planinu index-a da bi ti radilo stranicenje.
Please do not feed the Trolls!

Profesionalni sport je oksimoron. Profesionalni sportista je, najcesce, samo moron.
 
Odgovor na temu

[es] :: MySQL :: Polja koja mogu da budu al ne mora da znaci

Strane: 1 2

[ Pregleda: 9563 | Odgovora: 31 ] > FB > Twit

Postavi temu Odgovori

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