SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka |
|
Alati teme | Način prikaza |
04. 09. 2013. | #1 |
član
Certified
Datum učlanjenja: 23.02.2012
Poruke: 92
Hvala: 0
1.169 "Hvala" u 15 poruka
|
pitanje u vezi ID-a podataka
Imam tabelu u kojoj cuvam podatke po danu,smeni i broju racuna.
Pade mi napamet dilema koji pristup je bolji: 1) da cuvam posebno po danu,smeni i broju racuna pa kada trazim podatak trazim ga sa 3 WHERE-a 2)da cuvam u jednom polju kao integer koji se sastoji od dana,smene i broja racuna, npr u formatu (dan mi je redni broj dana u godini) dddssrrrr, a aplikacija da mi razbija informaciju na dan smenu i racun, a ukoliko radim query tipa samo ta smena, samo taj dan, onda bih trazio redove gde je id veci od i manji od (aplikacija bi radila logiku kreiranja upita) mozda je glupo pitanje ali me interesuje koji bi ste vi pristup koristili? srdačan pozdrav. |
04. 09. 2013. | #2 |
Ivan Dilber
Sir Write-a-Lot
|
pod 2 gubis puno fleksibilnosti a nista ne dobijas, osim minimalne ustede prostora...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
04. 09. 2013. | #3 |
član
Certified
Datum učlanjenja: 20.08.2008
Poruke: 58
Hvala: 21
144 "Hvala" u 15 poruka
|
1. opcija uvek.
kao što ivanhoe reče, 2 je nefleksibilno i nepotrebno komplikovano. |
05. 09. 2013. | #4 |
Ivan Dilber
Sir Write-a-Lot
|
da dodam samo da bi trebalo da kreiras index u bazi koji sadrzi sve 3 kolone, cime prakticno dobijes iste perfomanse kao da imas samo jedno integer polje...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
05. 09. 2013. | #5 |
član
Certified
Datum učlanjenja: 23.02.2012
Poruke: 92
Hvala: 0
1.169 "Hvala" u 15 poruka
|
Nisam mnog ulazio u to ali neko mi je rekao da nije dobro da tabela ima dosta kolona, da li je to istina?
U ovoj aplikaciji radim sa denormalizovanim podacima u tabeli koja vise lici na document oriented bazu i imam 30 kolona, pratkicno sve zapisujem u nju i sve citam iz nje. Da li mnogo gubim na performansama ovako? (ja cak mislim da dobijam jer ne koristim ni jedan join, ali drugi ne misle tako, ono sto ja mislim je da gubim samo storage) Hvala na odgovorima. |
05. 09. 2013. | #6 |
član
Certified
Datum učlanjenja: 23.02.2012
Poruke: 92
Hvala: 0
1.169 "Hvala" u 15 poruka
|
i jos jedno pitanje posto si pomenuo index:
U cemu je razlika da za ta tri polja stavim index i unique index? Da li unique index radi isto sto i index samo ne dozvoljava da budu iste vrednosti u kombinaciji ta tri polja? |
05. 09. 2013. | #7 |
Ivan Dilber
Sir Write-a-Lot
|
Broj kolona nema veze sa perfomansama, osim mozda u nekim ekstremnim slucajevima. Ranije kad je kao engine koriscen MyISAM onda je vazilo da treba izbegavati kolone sa varijabilnom duzinom (varchar, text), ali koliko ja znam to za InnoDB nije problem...
index za sva tri polja omogucava mysql-u da koristi index kad je WHERE oblika: dan=1 AND smena=2 AND racun=3, a tako je naravno brze nego da se koristi samo index po jednom polju, a ostala polja da se citaju sa diska. Takodje, ako je index nad poljima A,B,C (tacno tim redom) onda ce se taj isti index koristiti i kad su u WHERE samo polja A i B ili samo polje A.
__________________
Leadership is the art of getting people to want to do what you know must be done. Poslednja izmena od ivanhoe : 05. 09. 2013. u 19:48. |
06. 09. 2013. | #8 | |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Citat:
Neko pravilo je da se krene od normalizovane baze i denormalizaciji pristupa tek kad si zaista siguran da performanse nisu zadovoljavajuće. Denormalizacija komplikuje aplikativni kod i povećava mogućnost greške (da baza dođe u nekonzistentno stanje), a performanse od jednog trenutka mogu da postanu i gore nego da su podaci normalizovani. Naravno, moram da još jednom preporučim knjigu SQL Antipatterns koja vredi svakog centa. http://pragprog.com/book/bksqla/sql-antipatterns
__________________
blog |
|
|
|