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.   #1
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 Mogući problemi sa performansama sledećeg rešenja?

U activeCollabu svi objekti koji pripadaju projektu (taskovi, milestonei, poruke, fajlovi itd) dele neka zajednička svojstva:

obavezna:

- project_id
- parent_id
- name
- body
- visibility
- created_on
- created_by_id
- updated_on
- updated_by_id
- version
- position

samo za assignable objekte:

- due_on
- priority
- assignee_id
- resolution
- resolved_on
- resolved_by_id

Jedno rešenje koje mi je palo na pamet je da koristim inehritance mogućnosti ORM-a (Doctrine) i sve project objekte smestim u jednu tabelu. Dakle, da se odlepim od one table one class principa i sve project objekte smestim u jednu tabelu s tim da se razmikuje tip.

Znači, ta tabela bi imala sva navedena polja uz dodatak ID i TYPE_ID polja. Ono što me interesuje je koliko velike tabele (sa dosta polja i relativno velikim brojem upisa) utiču na performanse? Kada kažem relativno velika mislim na situaciju u kojima jedna klasična web aplikacija može da se nađe (do milion recorda recimo). Kako takva tabela scaluje (10K recorda, 100K recorda, 1M recorda itd)?

Kontam da ne bi smelo biti problema ako dobro rešim indekse i ne izvlačim sve kolone kada mi nisu potrebne. Pošto je InnoDB requirement nema table lockinga tako da je i rad sa celom tabelom oslobođen čekanja.

Razlog zašto mi se ovo rešenje izuzetno sviđa su agregacija podataka i mogućnost kreiranja složenih izveštaja: "Daj mi sve nerazrešene zadatke (taskovi ili milestonei) koji su assigneovani Iliji ili njegovoj kompaniji u tom i tom projektu, a pri tom pripadaju Feature requests listi i nisu markirani kao draft ili private i grupiši ih po prioritetu". Krajnji benefit je za korisnike: uz dobar interfejs activeCollab bi mogao imati strašno moćan reporting engine - definitivno jedan od boljih među dostupnim web rešenjima.

Interesuje me samo MySQL, 4.1+ with InnoDB support.
Ilija Studen je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #2
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

Ja koristim slicno rjesenje u svom internom frejmvorku, gdje imam glavni objekat/tabelu items, i u njoj cuvam slicne podatke kao sto ti hoces. Ostali objekti u tabelama imaju samo ono sto imaju dodatno u odnosu na items. Prilikom svakog citanja onda citas iz barem dvije tabele. Meni ovo zaista radi posao lijepo, i neke stvari bas olaksava.

Drupal koristi slicno rjesenje, i u njihovoj terminologiji to se zove node.

Uz dobro uradjene indekse i upite mislim da nema problema.
__________________
Donesi.com SrediMe
zira je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #3
marinowski
Igor Marinović
Expert
 
Avatar marinowski
 
Datum učlanjenja: 09.06.2005
Lokacija: Palić
Poruke: 549
Hvala: 31
39 "Hvala" u 17 poruka
marinowski is on a distinguished road
Pošaljite ICQ poruku za marinowski
Default

Ponasa se OK cak i za mnogo 'sire' tabele, limit je 32 indexa.
__________________
marinowski.com
marinowski je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #4
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

sa InnoDb ne bi trebalo da imas problema zbog lockinga tabele kod upisa/izmena, a cak i myISAM radi select sasvim ok sa milion recorda, dok god imas upite koji mogu da koriste indexe.

Eventualna optimizacija bi bila da u toj tabeli koristis samo fixed-width polja (znaci ID-jevi i razni flagovi, timestamps i tako to, samo ono sto ti u sustini i treba za WHERE deo), a da sav text drzis zasebno, pa ga joinujes po potrebi.
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #5
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 ivanhoe
Eventualna optimizacija bi bila da u toj tabeli koristis samo fixed-width polja (znaci ID-jevi i razni flagovi, timestamps i tako to, samo ono sto ti u sustini i treba za WHERE deo), a da sav text drzis zasebno, pa ga joinujes po potrebi.
U pravu si, detalje komotno mogu u zasebnu tabelu.

I mislio sam da je ovo prilično common rešenje kada imaš tonu sličnih objekata sa malim razlikama, ali ipak da proverim iskustva.
Ilija Studen je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #6
caboom
profesionalac
Qualified
 
Datum učlanjenja: 10.02.2006
Poruke: 181
Hvala: 2
20 "Hvala" u 11 poruka
caboom is on a distinguished road
Default

racunaj samo da join-ovanje nad velikim datasetom u mysql-u (~1m rec) moze biti prilican bottleneck cak i sa dobro postavljenim index-ima, ne znam da li se nesto promenilo po tom pitanju (pricalo se o boljoj implementaciji posto je imao prilicno primitivno realizovane join-ove sa nested loop-ovima sto znaci mnogo udaranja po index-ima), ali sumnjam da se nesto promenilo do sada.

Poslednja izmena od caboom : 22. 01. 2007. u 15:03.
caboom je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #7
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

taj se problem da resiti tako sto se joinovi zamene sub-selectima.. oni ok koriste indexe...
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #8
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Default

Ček, zar sub-select (u opštem slučaju) nije opasniji za perfomanse baze u odnosu na join?
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #9
caboom
profesionalac
Qualified
 
Datum učlanjenja: 10.02.2006
Poruke: 181
Hvala: 2
20 "Hvala" u 11 poruka
caboom is on a distinguished road
Default

jeste, nisam siguran da su sub-selectovi resenje na velikom broju record-a, mada kod mysql-a su moguca razna iznenadjenja
caboom je offline   Odgovorite uz citat
Staro 22. 01. 2007.   #10
degojs
I'm a PC too.
Wrote a book
 
Avatar degojs
 
Datum učlanjenja: 06.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
degojs će postati "faca" uskorodegojs će postati "faca" uskoro
Default

Č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?
__________________
Commercial-Free !!!

Poslednja izmena od degojs : 22. 01. 2007. u 22:13.
degojs je offline   Odgovorite uz citat
Odgovori



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 01:35.


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.