DevProTalk
Strana 2 od 2 < 1 2
Prikažite 40 poruka iz ove teme na jednoj stani

DevProTalk (http://www.devprotalk.com/index.php)
-   SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)
-   -   Mogući problemi sa performansama sledećeg rešenja? (http://www.devprotalk.com/showthread.php?t=2302)

Ilija Studen 22. 01. 2007. 21:20
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
} 

ivanhoe 22. 01. 2007. 23:53
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..

ivanhoe 23. 01. 2007. 00:24
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..]

zextra 23. 01. 2007. 10:54
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.

Peca 23. 01. 2007. 19:58
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]

Dejan Topalovic 23. 01. 2007. 21:27
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.

ivanhoe 23. 01. 2007. 21:28
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...

zira 23. 01. 2007. 21:36
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...


Vreme je GMT +2. Trenutno vreme je 15:20.
Strana 2 od 2 < 1 2
Prikažite 40 poruka iz ove teme na jednoj stani

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.