DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

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

Odgovori
 
Alati teme Način prikaza
Staro 22. 01. 2007.   #11
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

Citat:
Originalno napisao degojs
Čisto me interesuje --- kakvo je to crno ORM rešenje gde ti brineš o tome koji objekti/polja u koju tabelu i slično?

Tj. zašto se uopšte smaraš sa tim "problemom" ako si već odlučio da koristiš ORM alat?
ORM se brine o tome šta će gde raspodeliti, samo sam pitao da li takvo rešenje može biti loše što se performansi tiče. U pitanju je Doctrine i baš zahvaljujući tom ORM-u je cela priča jednostavna za implementaciju pošto omogućava izuzetno jednostavno nasleđivanje (one table one class ili one table many classes, kako ti već odgovara):

PHP kôd:
class ProjectObject extends Doctrine_Record {
  
// define common things
}

class 
ProjectTasks extends ProjectObject {
  
// inherit and add specific stuff


Poslednja izmena od Ilija Studen : 22. 01. 2007. u 22:25.
Ilija Studen je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #12
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

Citat:
Originalno napisao Petar Marić
Ček, zar sub-select (u opštem slučaju) nije opasniji za perfomanse baze u odnosu na join?

u opstem slucaju da, ali u opstem slucaju ni join ne bi smeo da bude problem na indexiranim tabelama

evo ovde jedan zanimljiv text gde se pominju i jedni i drugi slucajevi optimizacija: http://www.xaprb.com/blog/2006/04/30...oins-in-mysql/

zao mi je sto sam uvek lenj da zapisem negde kad naletim na tako nesto cudno, tako da sad nemam ni jedan primer, ali desilo mi se par puta da vidim tako neke skroz neocekivane rezultate...tako da ako vidis da je upit spor i da mora da se optimizuje, treba probati sve alternativne verzije pa videti sta je realno najbrze, posto su ponekad neke naizgled bezvezne stvari, potpuno nenadano, brze od skolskih resenja, a teporetski je to vrlo tesko predvideti..
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #13
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

evo iskopao sam u bookmarks jos jednu stranu sa lepim primerima: http://www.onlamp.com/pub/a/onlamp/2...m_clauses.html

[Edit ne radi posle 30 minuta, zato pisem posebnu poruku, sorry..]
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #14
zextra
Boris
Grand Master
 
Avatar zextra
 
Datum učlanjenja: 01.12.2005
Lokacija: Novi Sad
Poruke: 775
Hvala: 5
156 "Hvala" u 2 poruka
zextra is on a distinguished roadzextra is on a distinguished road
Default

Eksperimentisi dosta sa EXPLAIN, i uveri se da ti upiti koriste odgovarajuce indekse... Desilo mi se jednom da sam greskom napravio vise slicnih indeksa, pa je mysql koristio najgoru varijantu (ne secam se tacnog scenarija), ispalo je da je sporije sa indeksima nego bez indeksa. Naravno, uklanjanjem jednog suvisnog indeksa, sve je proradilo.
__________________
"It’s important to have goals when you pet. Otherwise you’re just rubbing another mammal for no reason." - Scott Adams
zextra je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #15
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

aj se vratite na temu, jer i mene interesuje

da li ce perfomanse biti slabije kod tabele koja ima manje polja u odnosu na tabelu koja ima vise polja? [a pri tome ne koristim ta polja za WHERE i ORDER, i polja su fixed-width].

da li postoji neki broj do koga broj polja nije problematican, a odakle vec pocinje da utice na perfomanse?
prostije, da li ce tabela sa 10 i 100 polja imati iste perfomanse? [indeksi isti za obe tabele]
__________________
Vesti | MyCity | Igrice | Zaštita od virusa
Peca je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #16
Dejan Topalovic
old school
Professional
 
Datum učlanjenja: 15.02.2006
Lokacija: Wien, Austria
Poruke: 304
Hvala: 121
47 "Hvala" u 26 poruka
Dejan Topalovic će postati "faca" uskoro
Pošaljite poruku preko MSN za Dejan Topalovic
Default

Ako imas Data Warehouse bazu, onda ti je bolje imati jednu tabelu sa vise polja, nego nekoliko tabela sa manje polja, jer je tada full table scan brzi od visestrukog index lookup join-a (npr. star transformation join).

Ako imas OLTP bazu, onda ti je bolje imati tabele sa manje polja.

Ako imas objekt sa vise atributa od kojih su samo par atributa kljucni, onda kreiraj dvije ili vise tabela: jednu manju sa kljucnim atributima (poljima) i jednu ili vise njih sa sekundarnim atributima, koje ces medjusobno povezati preko kljuceva. Mozes potom tu sekundarnu tabelu i kompresovati ukoliko ne radis cesto update na njoj, jer se pri selektovanju dobija na brzini.

Nije dobro stavljati previse indexa na tabelu (tzv. overindexed table), jer se pri DML operacijama (INSERT, UPDATE i DELETE) usporava cijeli proces zbog aktualizovanja indexa. Pogotovo nakon ucestalog UPDATE-a ili DELETE-a pozeljno je uraditi rebuild indexa i OPTIMIZE tabele, jer se stvaraju rupe (gaps) izmedju zapisa.

Uprkos dobro dizajniranoj strukturi baze, vecina programera napise lose i neperformantne upite, kojima usporavaju cijelu aplikaciju. U vecini slucajeva se prepravljanjem SQL upita moze puno dobiti na brzini.

Osim toga, ako imas svoj server, mozes podesavati i konfiguracijske parametre (cache buffer, file-per-table, uraditi stripping tabela na vise hard diskova i td.).

U svakom slucaju bez obzira sta kazu teorija i EXPLAIN PLAN, samo uzastopnim testiranjem i mijenjanjem postavki i SQL upita mozes doci do opipljivih rezultata.
__________________
Blog: Baze podataka
------------------------
Oracle OCP DBA
Oracle OCE SQL Expert
Oracle OCP Developer
Certified MySQL DBA
Dejan Topalovic je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #17
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

Citat:
Originalno napisao Peca
da li postoji neki broj do koga broj polja nije problematican, a odakle vec pocinje da utice na perfomanse?
prostije, da li ce tabela sa 10 i 100 polja imati iste perfomanse? [indeksi isti za obe tabele]
pod poljima mislis na kolone ili recorde ?

sa 10 i 10000 recorda nema neke bitne razlike. Ali za 3-4 miliona ima razlike, cak i na indexiranim poljima, jer indexi postanu glomazni. Preko 3-4 miliona recorda i 2GB velicine na disku nije zdravo raditi sa myISAM tabelama, to znam iz iskustva (za INNODB ne znam). Takodje joinovi na tako velikim tabelama pocnu da se vuku uzasno..

sto se broja kolona tice, tu su male razlike, mislim da ne pravi nikakvu razliku, sem ako napravis previse indexa sto usporava upis i izmene...
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 23. 01. 2007.   #18
zira
Vladan Zirojević
Grand Master
 
Datum učlanjenja: 09.06.2006
Lokacija: Beograd/Trebinje
Poruke: 903
Hvala: 106
183 "Hvala" u 82 poruka
zira ima spektakularnu auruzira ima spektakularnu auruzira ima spektakularnu auru
Pošaljite ICQ poruku za zira Pošaljite poruku preko Skype™ za zira
Default

Nemam mjerenja, ali cini mi se da sam procitao da nije preporucljivo imati ni ogroman broj kolona (recimo 100+). I da to utice na performanse. Nisam probao, tako da pisem iz sjecanja...
__________________
Donesi.com SrediMe
zira je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Dajte predlog rešenja - Photo voting community istok Web aplikacije, web servisi i software 2 22. 01. 2009. 11:47
www.askeet.com - Web 2.0 servis od ideje do gotovog rešenja Ilija Studen PHP 1 26. 12. 2005. 19:06
Jednostavan php album sa sledećim opcijama mungos PHP 9 24. 06. 2005. 15:21


Vreme je GMT +2. Trenutno vreme je 07:04.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.