Srodne teme

14.04.2024. Re: Gde je Kejt? (samo pogrešni odgovori)
24.04.2001. 2001/01/04 NASA switches from Oracle to MySQL
14.08.2002. MySql Probelem
31.01.2003. MySQL i apache
21.01.2003. MySQL problem
28.07.2003. Perl & MySql
08.02.2004. Jedna baza ili vise njih za bolji performance?
21.04.2004. Veliki web sistem zasnovan na MySQL-u
25.07.2004. mysql daemon i jabberd na Slacku
05.02.2005. mysql problemi na Slack10

Navigacija

Brisanje liste

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

MySQL dizajn za bolje performanse

[es] :: MySQL :: MySQL dizajn za bolje performanse

Strane: 1 2

[ Pregleda: 11236 | Odgovora: 32 ] > FB > Twit

Autor

mojeKorIme
BiH

Član broj: 59512
Poruke: 350
92.36.254.*

+1 Profil

MySQL dizajn za bolje performanse

^{10.03.2009. u 06:50 - pre 183 meseci}

U prethodnoj temi (Optimizacija MySQL servera) je spomenuto da je pored najbolje optimizacije servera, ako ne projektujemo logicki bazu podataka necemo imati sistem koji "radi kako treba". //imam iskustva sa ovim problemom

Na šta treba obratiti pažnju prilikom projektovanja baze podataka? kako postaiti pravilno indekse, jer oni iako mogu pomoći u nekim slučajevima (select ..) mogu i usporiti unos podataka.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 12:31 - pre 183 meseci}

bojim se da ovde ne mogu da budem toliko koristan :( .... posto za ovo vec mora da se ide u skolu i da se malo uci teorija :)

neke osnovne stvari na koje treba obratiti paznju
- baza treba da bude normalizovana
- mysql moze (za sada) u jednom upitu da koristi samo 3 indexa tako da - pravite kompozitne indexe gde je to potrebno
- indexi u tabeli usporavaju insert
- ako nam je potrebno da nadjemo kolonu A indexi (A) i (A,B) su isti .. tj ako u tabeli postoji index (A,B) index (A) je visak (index (B) nije !)
- imenovanje tabela moze da pomogne, ovo su MOJE preference (nisu kompatibilne sa, recimo, WB-om :) )
o Tabele imenujte JEDNINOM - dakle ENTITET
o Kolone imenujte ENTITET_ATRIBUT
o Ne koristite sva velika slova :D - mnogo ruzno izgleda

dakle neki primer

Code:

create table `korisnik` (`korisnik_id` unsigned bigint primary key auto_increment, `korisnik_ime` varchar(30), `korisnik_prezime` varchar(30), `lokacija_id` unsigned bigint, key (`lokacija_id`));
create table `lokacija` (`lokacija_id` unsigned bigint primary key auto_increment, ....

ako imate "pod entitete" tipa korisnik_lokacija_grad, korisnik_lokacija_drzava ... znaci da DB model nije normalizovan

ako imate IF() / Switch u upitu u 99% clujajeva znaci da DB model nije optimizovan

dalje od ovoga ... uputstvo za erwin :) .. odlicna knjiga za optimizaciju db modela ... cak stavise, neka profanka sa beogradskog pmf-a koja drzi "baze" je isto uputstvo prevela od reci do reci i izdala kao knjigu za svoj predmet :D :D :D ... cak deluje da su to neki studenti prevodili posto se vidi 10 strana jedan nacin pisanja, pa 10 strana drugi, pa 10 strana treci ...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 12:55 - pre 183 meseci}

evo iskopao sam neki svoj stari text na ovu temu ..

Modeliranje baze podataka - Normalizacija

Normalizacija modela baze podataka je proces definisanja strukture baze podataka (entiteti, atributi i relacije) u optimalni format. Standardne normalne forme su aditivne, dakle ako je neki model sveden na trecu normalnu formu, automatski je u drugoj i prvoj normalnoj formi. Osnovne forme DB modela su:

1NF: Prva normalna forma
2NF: Druga normalna forma
3NF: Treca normalna forma
BCNF: Boyce/Codd normalna forma
4NF: Cetvrta normalna forma (aka izolacija nezavisnih relacija)
5NF: Peta normalna forma (aka izolacija semanticki povezanih relacija)
DKNF: Domen/Kljuc normalna forma (aka savrsen model)

Svodjenje modela na prvu normalnu formu
Krenucemo od jednostavne strukture, imamo spisak clanova foruma koji imaju nekakvo znanje o raznim materijama. Neki clanovi znaju o muzici, neki o hardware-u dok se neki bolje snalaze sa linux-om; naravno, postoje i oni koji vrlo dobro poznaju i hardware i muziku etc. Primer jednostavne tabele bi izgledao ovako:

Code:

ID: 1
KORISNIK: pera peric
ZIVI: Srbija
ZNANJE: Audio

ID: 2
KORISNIK: mika mikic
ZIVI: Srbija
ZNANJE: Video

ID: 3
KORISNIK: zikica zikic
ZIVI: Srbija
ZNANJE: Audio, Video, Hardware, Windows

ID: 4
KORISNIK: mali perica
ZIVI: Srbija
ZNANJE: Audio, Video, Baze, Hardware, Windows, Linux, Programiranje

ID: 5
KORISNIK: mali zikica
ZIVI: BIH
ZNANJE: Programiranje, Hardware

Ako zelimo da saznamo koji korisnik zna "video" moramo proci kroz sve korisnike, proveriti sadrzaj polja "znanje" i pregledati prilicno nepregledno polje "znanje" te otkriti da li doticni korisnik zna "video" ili ne ... Mane ovakve organizacije su ocigledne (brzina, preglednost...) te je ovo vrlo nepraktican nacin za cuvanje informacija.

Klasificiranje podataka u zasebne tabele ce "prisrediti" podatke i omoguciti laksu pretragu. Razdvajanje repetitivnih podataka u zasebne tabele nasu strukturu dovodi u prvu normalnu formu.

Iz naseg primera (gde je sve bilo nagurano u istu tabelu), dobijamo 2 odvojene tabele:

TABELA: KORISNIK

Code:

KORISNIK_ID: 1
KORISNIK_IME: pera peric
KORISNIK_ZIVI: Srbija

KORISNIK_ID: 2
KORISNIK_IME: mika mikic
KORISNIK_ZIVI: Srbija

KORISNIK_ID: 3
KORISNIK_IME: zikica zikic
KORISNIK_ZIVI: Srbija

KORISNIK_ID: 4
KORISNIK_IME: mali perica
KORISNIK_ZIVI: Srbija

KORISNIK_ID: 5
KORISNIK_IME: mali zikica
KORISNIK_ZIVI: BIH

TABELA: ZNANJE

Code:

ZNANJE_ID: 1
KORISNIK_ID: 1
ZNANJE_IME: Audio

ZNANJE_ID: 2
KORISNIK_ID: 2
ZNANJE_IME: VIDEO

ZNANJE_ID: 3
KORISNIK_ID: 3
ZNANJE_IME: Audio

ZNANJE_ID: 4
KORISNIK_ID: 3
ZNANJE_IME: Video

ZNANJE_ID: 5
KORISNIK_ID: 3
ZNANJE_IME: Hardware

ZNANJE_ID: 6
KORISNIK_ID: 3
ZNANJE_IME: Windows

ZNANJE_ID: 7
KORISNIK_ID: 4
ZNANJE_IME: Audio

ZNANJE_ID: 8
KORISNIK_ID: 4
ZNANJE_IME: Video

ZNANJE_ID: 9
KORISNIK_ID: 4
ZNANJE_IME: Baze

ZNANJE_ID: 10
KORISNIK_ID: 4
ZNANJE_IME: Hardware

ZNANJE_ID: 11
KORISNIK_ID: 4
ZNANJE_IME: Windows

ZNANJE_ID: 12
KORISNIK_ID: 4
ZNANJE_IME: Linux

ZNANJE_ID: 13
KORISNIK_ID: 4
ZNANJE_IME: Programiranje

ZNANJE_ID: 14
KORISNIK_ID: 5
ZNANJE_IME: Hardware

ZNANJE_ID: 15
KORISNIK_ID: 5
ZNANJE_IME: Programiranje

Sada je pitanje "koji korisnik zna video?" mnogo lakse odgovoriti.

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 12:56 - pre 183 meseci}

Svodjenje modela na drugu normalnu formu

Ako pogledamo tabelu "ZNANJE" iz prethodnog primer, primeticemo da nam se podaci dupliciraju. Za razliku od tabele "KORISNIK" gde atribut KORISNIK_ID definise slog tabele, u tabeli KORISNIK slog se definisu KORISNIK_ID i ZNANJE_ID atributi zajedno. Ovo u nekim slucajevima moze da ima smisla, ali u nasem slucaju, gde ime "znanja" realno nije ni u kakvoj relaciji sa korisnikom i bezrazlozno se multiplicira u tabeli, mozemo zakljuciti da nam se podaci "dupliraju". Ovo dupliranje podataka, osim sto se odrazava na prostor potreban za cuvanje istih, otezava operacije sa bazom.

Ako na primer zelite da promenite ime jednog znanje (na primer zelite da "Audio" postane "Rad sa zvukom") morate to ime promeniti na vise mesta umesto samo na jednom (anomalija pri promeni). Dalje, pretpostavite da "mali perica" ode sa foruma; u tom slucaju treba obrisati sve slogove vezane za njega; u tom slucaju, potpuno ce nestati referenca da je znanje "Linux" postojalo na forumu (anomalija pri brisanju).

Da bi ste zaobisli ove anomalije, potrebna vam je druga normalna forma.

Da bi "razvili" nasu bazu u drugu normalnu formu, potrebno je da razdvojimo atribute koji zavise od oba kljuca koji definisu tabelu "ZNANJE". Rezultat ce biti dve tabele:

TABELA: ZNANJE

Code:

ZNANJE_ID: 1
ZNANJE_IME: Audio

ZNANJE_ID: 2
ZNANJE_IME: Video

ZNANJE_ID: 3
ZNANJE_IME: Hardware

ZNANJE_ID: 4
ZNANJE_IME: Windows

ZNANJE_ID: 5
ZNANJE_IME: Baze

ZNANJE_ID: 6
ZNANJE_IME: Linux

ZNANJE_ID: 7
ZNANJE_IME: Programiranje

TABELA: KORISNIK_ZNANJE

Code:

ZNANJE_ID: 1
KORISNIK_ID: 1

ZNANJE_ID: 2
KORISNIK_ID: 2

ZNANJE_ID: 1
KORISNIK_ID: 3

ZNANJE_ID: 2
KORISNIK_ID: 3

ZNANJE_ID: 3
KORISNIK_ID: 3

ZNANJE_ID: 4
KORISNIK_ID: 3

ZNANJE_ID: 1
KORISNIK_ID: 4

ZNANJE_ID: 2
KORISNIK_ID: 4

ZNANJE_ID: 3
KORISNIK_ID: 4

ZNANJE_ID: 4
KORISNIK_ID: 4

ZNANJE_ID: 5
KORISNIK_ID: 4

ZNANJE_ID: 6
KORISNIK_ID: 4

ZNANJE_ID: 7
KORISNIK_ID: 4

ZNANJE_ID: 3
KORISNIK_ID: 5

ZNANJE_ID: 7
KORISNIK_ID: 5

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 12:57 - pre 183 meseci}

Svodjenje modela na trecu normalnu formu

Ako pogledamo malo bolje tabelu "KORISNIK" videcemo da iako ispunjava i prvu i drugu normalnu formu, atribut "ZIVI" nije direktno zavistan od ID-a korisnika (primarnog kljuca). Da bi postigli trecu normalnu formu, taj podatak mora da se odvoji u zasebnu tabelu. Zasto? Ako uzmemo na primer da "mali zikica" napusti forum, te se slogovi koji njega definisu obrisu, nestace trag o "BIH" (anomalija pri brisanju) ili ako "Srbija" ponovo promeni ime u "Republika Beograd sa okolinom", to ime moramo promeniti na vise od jednog mesta (anomalija pri promeni). Razlaganje na trecu normalnu formu zahteva da podatak o "ZIVI" prebacimo u zaseban entitet.

TABELA: DRZAVA

Code:

DRZAVA_ID: 1
DRZAVA_IME: Srbija

DRZAVA_ID: 2
DRZAVA_ID: BIH

TABELA: KORISNIK

Code:

KORISNIK_ID: 1
KORISNIK_IME: pera peric
DRZAVA_ID: 1

KORISNIK_ID: 2
KORISNIK_IME: mika mikic
DRZAVA_ID: 1

KORISNIK_ID: 3
KORISNIK_IME: zikica zikic
DRZAVA_ID: 1

KORISNIK_ID: 4
KORISNIK_IME: mali perica
DRZAVA_ID: 1

KORISNIK_ID: 5
KORISNIK_IME: mali zikica
DRZAVA_ID: 2

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 13:01 - pre 183 meseci}

i "graficki":

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Prikačeni fajlovi

1nf.gif - 5.48k

2nf.gif - 6.45k

3nf.gif - 6.69k

Odgovor na temu

Zmaj
Predrag Krstić
web developer
Zrenjanin

Član broj: 1035
Poruke: 382

Sajt: https://pkrstic.wordpress..

+4 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 23:03 - pre 183 meseci}

sta reci, osim, skidam kapu na ovolikom trudu... odavno nisam procitao ovoliko kvalitetnih postova, nevezano za temu i sobu na ovom forumu... e da je vise ovakvih postova...

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.03.2009. u 23:34 - pre 183 meseci}

fala pedja, koliko se ja secam i vi u vast-u koristite mysql :) .. mozete da podelite iskustva :) ... doduse, vi ga uglavnom koristite kao "communication layer" nego kao bazu podataka :) no to je isto zanimljiva primena (koristiti bazu podataka za interprocess komunikaciju na oblaku - posto se to sto vi radite - sa tim brojem masina - ladno moze nazvati oblak)

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

mojeKorIme
BiH

Član broj: 59512
Poruke: 350
92.36.242.*

+1 Profil

Re: MySQL dizajn za bolje performanse

^{11.03.2009. u 07:21 - pre 183 meseci}

nema me neko vrijeme ..a vec se postavi nekoliko vrlo kvalitetnih postova..
gdje si bio Bogdane dok sam studirao... bolji post o normalizaciji još nisam pročitao..:D..
PS Na koju normu je najbolje svesti sistem.. ima li neko pravilo to koje određuje?

_{[Ovu poruku je menjao mojeKorIme dana 11.03.2009. u 08:45 GMT+1]}

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{11.03.2009. u 14:02 - pre 183 meseci}

Citat:

gdje si bio Bogdane dok sam studirao...

eh... za kompjuterom verovatno ...

Citat:

bolji post o normalizaciji još nisam pročitao..:D..

post je par godina star... planirao sam i ostale norme da obradim al nikad nisam nasao dovoljno slobodnog vremena ... ne ide mi bas pisanje ... posebno ne na srpskom, posto nikad o ovim stvarima ne diskutujem na srpskom ... osim evo sad na ovom forumu i tamo na onom mom mysql blogu .. (sve to tek par meseci)...

Citat:

PS Na koju normu je najbolje svesti sistem.. ima li neko pravilo to koje određuje?

there is no silver bullet :D

teoretski, sto "normalnija" baza to bolje .. e sad, vrlo cesto, zbog nesavrsenosti rdbms-a, mi radimo denormalizaciju baze i dupliciramo neke podatke namerno, da bi dobili na brzini .. ono sto dba/dbdev-a cini velikim je da zna kada, koliko i zasto ce to da uradi, da ima mere i slicno ...

dakle teoretski DKNF je "idealna forma" .. prakticno .... nije lako reci, normalne forme preko trece krecu gadno da komplikuju stvari :D .. na vecini domacih fakulteta ih ni ne spominju ni imenom a kamoli objasnjavaju kako sljakaju :D (ok, nije neki reper, skole nam nisu ni za ...) ali mozes pogledati par referenci ...

http://en.wikipedia.org/wiki/Database_normalization
http://en.wikipedia.org/wiki/Boyce-Codd_normal_form
...
http://en.wikipedia.org/wiki/Domain/key_normal_form
...
http://en.wikipedia.org/wiki/Sixth_normal_form

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Re: MySQL dizajn za bolje performanse

^{11.03.2009. u 19:23 - pre 183 meseci}

Svaka cast za postove!!
Jedna mi je stvar zapela za oko (onako, ekserom) :)

Citat:

o Tabele imenujte JEDNINOM - dakle ENTITET
o Kolone imenujte ENTITET_ATRIBUT

Ako dobro ovo shvatam znaci:
table_name = ucenik
col_name = ucenik_ocjena

I onda malo dugacko izgleda query tipa
SELECT ucenik.ucenik_ocjena, ucenik.ucenik_prosjek, ucenik.ucenik_vladanje .....

Po meni vishe ima smisla koristiti za imena kolona ATRIBUT jer:
- kad radis sa jednom tabelom, naravno da su svi to atributi od te tabele i nista se ne mjesa
- kad radis sa vishe tabela, naravno da ces koristiti prefix tabele ispred kolone da napravis razliku.

Mozda ima jos nesto sto ja ne vidim??

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{11.03.2009. u 23:21 - pre 183 meseci}

Citat:

misk0:
Jedna mi je stvar zapela za oko (onako, ekserom) :)

Ako dobro ovo shvatam znaci:
table_name = ucenik
col_name = ucenik_ocjena

I onda malo dugacko izgleda query tipa
SELECT ucenik.ucenik_ocjena, ucenik.ucenik_prosjek, ucenik.ucenik_vladanje .....

jup, bude "dugacak upit" to jeste, ali ...

1. mnogo je lakse za normalizaciju, tj. vidi se iz aviona ako ne odradis normalizaciju kako treba
2. ako u tabeli EKSER imas polje CEKIC_ID vidi se iz aviona da je cekic_id strani kljuc iz tabele cekic ..
3. ako imas t1.t1_id, t1.t2_id, t2.t2_id mozes da radis join using (t2_id) sto inace ne bi mogao ...
4. ako radis upit select t1.ucenik_id, t2.ucenik_sveska, t3.grad_zip from ucenik t1, ucenik t2, grad t3 where .... ne moras da prodjes kroz ceo upit (da ucenik t1, ucenik t2 mogu da budu potrebni) da bi video sta je gde :) ja inace preferiram ti sa t1/t2/t3 vrlo cesto da radim zbog lakse optimizacije upita kasnije (cisto nacin na koji ja radim, nema veze sa realnim potrebama)

e sad, to je moja preferenca .. ide jos iz vremena kada innodb nije postojao a Monti ubedjivao svet da je svako kome trebaju strani kljucevi los developer. Za imenovanje atributa postoje razni predlozi, ne postoji usvojen standard. Ono oko cega se svi slazu je da entitete zovete jedninom, dakle nije "ucenici" nego "ucenik", sto se samog atributa tice, misljenja su podeljena - pogledaj samo kako mysql workbench naziva imena polja, posebno ona koja su deo stranog kljuca ...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.sun.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{12.03.2009. u 02:36 - pre 183 meseci}

Evo nekih "tudjih" pogleda na imenovanje entiteta i atributa:
http://www.peachpit.com/articl...cle.aspx?p=30885&seqNum=10
http://justinsomnia.org/2003/0...-naming-conventions-and-style/
http://www.interaktonline.com/....html?id_art=24&id_asc=221

generalno, "pravilo" je koristenje jednine za imena tabela "mada se mnogi zale i to ne postuju" ..
"prefix the name of every field with the table name, excluding foreign key" je takodje je "pravilo" ali ga mnogi ne postuju

etc etc ...
dakle, sve u svemu .. stil / konvencija koju ja koristim / zagovaram je "matoro (ne)pisano pravilo" i danas se mnog o ta pravila oglusuju / namerno ih, sa objasnjenjem ne postuju. Kao sto sam naveo, sam MySQL u WB-u ne postuje tu konvenciju .. no, ja sam navikao i zagovaram te neke "stare sisteme vrednosti" :) ... navika je cudo

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

Leksiko

Član broj: 170528
Poruke: 19
*.kpn.net.

Profil

Re: MySQL dizajn za bolje performanse

^{12.03.2009. u 09:57 - pre 183 meseci}

Bravo, sjajna tema i sjajni postovi.

Odgovor na temu

Drasko M
Beograd

Član broj: 136941
Poruke: 37
91.148.91.*

Sajt: www.direktnaprodaja.com

+1 Profil

Re: MySQL dizajn za bolje performanse

^{12.03.2009. u 11:40 - pre 183 meseci}

Ovaj tekst o normalizacijama je zaista bio koristan mada mi je na neki nacin ostalo nejasno zasto se normalizacije nazivaju:prva, druga, treca..
Hocu reci, da meni sve normalizacije izgledaju isto - razlaze se neki kompleksni redundantni entitet na jednostavnije neredundantne. U zavisnosti od 'slozenosti' pocetne strukture proces razlaganja moze da ima jedan ili vise nivoa.

Sto se tice 'dobre prakse' do kog stepena treba ici to zavisi od toga sta zelite da postignete.
Ukoliko vam je cilj 'konzistentnost podataka' tj. da se izmene u jednom entitetu reflektuju i na drugim entitetima onda svakako sto veci stepen normalizacije.
Nekad vam to nece biti cilj.
Zamislite da imate tabelu proizvodi koja ima polja proizvodID i cena
Druga tabela su porudzbine gde imate porudzbinaID , kolicina , ukupna cena

Ukupna cena bi mogao biti redundantan podatak jer se moze dobiti iz cene (tabela proizvodi) i kolicine (tabela porudzbine)
Medjutim, mozda je poslovna politika takva da cena proizvoda moze biti promenjiva i da je za realizovanu porudzbinu bitna cena proizvoda u tom trenutku(trenutku prodaje) .Onda vam svakako polje ukupna cena nece biti na odmet.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{12.03.2009. u 18:03 - pre 183 meseci}

Citat:

Drasko M: Ovaj tekst o normalizacijama je zaista bio koristan mada mi je na neki nacin ostalo nejasno zasto se normalizacije nazivaju:prva, druga, treca..
Hocu reci, da meni sve normalizacije izgledaju isto - razlaze se neki kompleksni redundantni entitet na jednostavnije neredundantne. U zavisnosti od 'slozenosti' pocetne strukture proces razlaganja moze da ima jedan ili vise nivoa.

sam kazes "proces razlaganja moze da ima jedan ili vise nivoa" ..

no, normalne forme su rangirane po broju resenja koje nude ... manji broj normalne forme, manje problema resava ... no .. taj deo teorije stvarni nije bitno ... da sam pisao onako kako lelemu.. ovi na faxu kod nas em niko nista ne bi razumeo em bi se svi smorili ...

sto se tice denormalizacije .. kao sto rekoh, zavisno od zahteva, zavisno od rdbms-a denormalizacija se radi u nekim slucajevima. tvoj primer nije bas idealan posto si ti dao primer kada taj info ne moze da se izvuce iz tabele te samim tim podatak nije redundantan jer "politika takva da cena proizvoda moze biti promenjiva" - sa ovim zahtevom ti realno nemas nacin da izvadis taj podatak osim da ga cuvas / nije redundantan

ali na primer ako imamo (slican / isti slucaj)

tabela: istorija cena
[pk] proizvod_id
[pk] proizvod_datumcene
proizvod_cena

tabela: racun
racun_id
racun_datum

tabela: artikli
[pk] racun_id
[pk] prioizvod_id
kolicina
cena

ti mozes da na racunu znas cenu artikla tako sto ces proveriti cenu artikla u tabeli istorija cena na dan racuna ... tj artikli.cena je cena iz istorije cena na datum racuna * kolicina :) ... e sada, posto je tabela artikli "write only" .. tu se samo dodaje, nema nikakvih promena - to se prodao po toj ceni, mi stavimo atribut cena u tabelu artikli koji je redundantan (rekoh kako ga mozemo izracunati) ali tih par bajtova po neindeksiranoj koloni nece mnogo smetati a bilo kakav report ce biti mnooooooooooogo brzi / jednostavniji ....

da ne knaram ... sad sam ja poceo da lele.udim sa teorijom koja nicemu ne sluzi ... cela ta teorija je osmisljena da bi se stvar koju svaki dobar dba radi "po osecaju" iz prve, objasnila onima sa "zeljom" ...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

Shavgan
.NET Developer

Član broj: 169768
Poruke: 91
92.36.254.*

+1 Profil

Re: MySQL dizajn za bolje performanse

^{12.03.2009. u 23:49 - pre 183 meseci}

Za bogdana jedan veliki RESPECT... svaka cast majstore uvijek imas umjeren odgovor sa dosta korisnih informacija..predlazem ti ako imas vremena da uradis jedan vid video turtorijala za rad sa bazama koristeci mysql sistem...mislim da bi to bio pun pogodak..nesto slicno je uradio Istok za rad u Flash-u

Odgovor na temu

Drasko M
Beograd

Član broj: 136941
Poruke: 37
91.148.81.*

Sajt: www.direktnaprodaja.com

+1 Profil

Re: MySQL dizajn za bolje performanse

^{13.03.2009. u 00:24 - pre 183 meseci}

Hvala na odgovoru., lepo je imati coveka iz Sun-a , odnosno MySql Development Team-a na ovom forumu - informacije iz prve ruke :)

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{13.03.2009. u 01:13 - pre 183 meseci}

Citat:

Shavgan:vid video turtorijala za rad sa bazama koristeci mysql sistem

rad sa bazama ne podrazumeva nista "graficki" da bi bilo kakav "film" pomogao, to nije program koji ti koristis pa da imas 30 opcija koje neko treba da objasni kroz primere ... ja licno ne koristim nikakav gui za rad sa mysql-om, za zivota sam koristio nekoliko, na windozi je ems mysql manager najbolji koji sam probao (500$ kosta i prave ga rumuni ili madjari ili tako neka firma iz okoline) .. koristim mysql cli za sve sto imam da radim sa mysql-om .. od grafickih alata koristim WorkBench i ne znam ga nista bolje nego sto bi ti znao da kroz njega klikces 10 dana ... ali WB nema bas mnogo veze sa mysql-om

Citat:

Drasko M: Hvala na odgovoru., lepo je imati coveka iz Sun-a , odnosno MySql Development Team-a na ovom forumu - informacije iz prve ruke :)

nema na cemu, no, ja radim u timu "MySQL Support", "MySQL Development" team je drugi tim (sa kojima ja tesno saradjujem, komuniciram svaki dan, koje cimam za dodatne informacije i slicno)... Moj posao je konsalting i podrska vezana za MySQL Cluster i u slobodno vreme radim development za MySQL Cluster .. Generalno, mi iz "support" tima radimo i development i konsalting, oni iz developmenta rade samo development i oni iz konsaltinga rade samo konsalting. Malo je to "komplikovano organizovano" ... mi radimo konsalting koji je ukljucen u suipport (gold i platinum kontrakti), dakle sa postojecim klijentima, a "konsalting grupa" radi sa firmama koje nisu klijenti vec uzimaju ili 1time konsalting ili uzimaju pre-sales konsalting; tako da niti radim support/konsalting za MySQL Enterprise Server, MySQL Enterprise Monitor, MySQL Workbench ... niti mi je to u opisu posla :) sve ovo napisano je mogao da napise bilo koji malo obrazovaniji DBA, nisu ovo nikakve "tajne formule iz MySQL laboratorije" .. na zalost, problem je sto ti "malo obrazovaniji DBA" misle da su uvatili .... za .... pa svoje znanje cuvaju kao zmija noge i prave od svega toga veliku filozofiju ... evo cujes da DB2 DBA-ovi pricaju kako DB2 ne moze da se nauci za ceo zivot a da bi postao oracle DBA moras 12 godina da ucis ... za 12 godina ljudi postanu hirurzi na mozgu, rade doktorate na novim tehnologijama, ceo database sistem se napise za godinu dana ... tako da .. sve je to lelemudjenje od strane ljudi koji su odlicno placeni da ne rade nista ... i treba da budu placeni posto imaju odgovoran i bitan posao, i kada ne rade nista znaci da svoj posao rade odlicno .. sve je to ok, ali treba znati sta su bubrezi a sta ....

ja kada bih pisao te stvari koje radim, malo kome bi bile interesantne (na zalost malo ko bi ih i razumeo posto je potrebno znanje o specificnoj problematici) a 99.9999999% ljudi sa tim nikada nece doci u kontakt ... oni koji dolaze sa tim u kontakt su vec klijenti :) i smaraju me na dnevnoj osnovi :)

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

dusaSaLagera
Kuci, Nema

Član broj: 191594
Poruke: 16
*.dynamic.sbb.rs.

Profil

Re: MySQL dizajn za bolje performanse

^{17.03.2009. u 14:14 - pre 183 meseci}

Citat:

- ako nam je potrebno da nadjemo kolonu A indexi (A) i (A,B) su isti .. tj ako u tabeli postoji index (A,B) index (A) je visak (index (B) nije !)

Recimo ako imam tabelu friend(+s plus prefix pride :) ) sa kolonama friend_id1,friend_id2,...jos par kolona
Primarni kljuc mi je kompozitni friend_id1,friend_id2.
Dugo sam se dvoumio da li bi ikakvu korist dobio ako bih stavio kljuc i na friend_id1 jer se u where/joinima uglavnom ova kolona pojavljuje. Ako sam te dobro razumeo, moj pristup je ispravan, jel tako?

Takodje(ovako iz prve ruke da mi odgovoris ako mozes), u kolikoj meri je insert/update/select nad myISAM tabelama brze u odnosu na InnoDB engine? Isto tako sam primetio da na vecini hostinga na kojima sam hostovao svoje web aplikacije InnoDB nije dobro podesen, pa se precesto desavalo pucanje(a uz to nisam znao tad za sve prednosti MySQLi - tipa automatski rollback transakcija i u slucaju pucanja skripte na nepredvidjenom delu - pre rollbacka...da napomenem - ako nije jasno, pricam o PHP) . Da li mi mozes dati neke inside informacije o cemu(kojim varijablama) da vodim racuna prilikom podesavanja mysql-a za InnoDB? Posto sada imam pristup svom serveru(tj nije bas moj, ali duga je to prica :) ). Da napomenem, recimo da mi je neki optimum da sajt radi normalno tako sto sam stavio 500 konekcija(mada cu verovatno morati vise) ka bazi u jednom trenutku. Dok je bilo na default podesavanjima(mislim da je oko 100 konekcija), ponestajalo je konekcija svakih par sekundi kad navale useri+botovi :)

Odgovor na temu

[es] :: MySQL :: MySQL dizajn za bolje performanse

Strane: 1 2

[ Pregleda: 11236 | Odgovora: 32 ] > FB > Twit

Srodne teme

20.10.2005. Problemi sa MySql Administratir - om
11.11.2005. Performanse nakon overclockovanja?
08.11.2005. Hosting i broj mysql baza
05.07.2006. Slack 10.2 i mysql
14.10.2006. Potreban PHP/MySQL programer
20.11.2006. Potreban partner, web dizajn, php/mysql
04.02.2007. Problem pri konfiguraciji MySQL Databaze
18.03.2007. Povezivanje C# i MySQL
29.05.2007. C# i dizajn web stranica, pitanje...

Navigacija

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