Na ovaj način bi svaka tablica u početku imala oko 40 000 rezultata, te 15ak novih dnevno.
Da li je ovo potrebno? Do kolikog broja zapisa program ne bi trebao “zapinjati”?
(pod pretpostavkom da će program koristiti najviše do 100 ljudi istovremeno)
p.s.Izrada priručne memorije nije opcija jer postoji velik broj varijabli kod pretraživanja, a nema određene kombinacije koja se najčešće ponavlja…
Prem izloženom tvoj dizajn baze “sucks big time”, ali za neko konkretnije riješenje potrebni su i neki konkretniji podaci. Čemu tablica služi, kakvi podaci će biti spremani, što su to “objekti”, “ime”, “polje1”, “polje2” itd, itd,. Iz tvog napisanog nitko ne može razlučiti što imaš, što radiš i što bi htio. Ovo što ti pitaš je isto kao da sve te ojekte spremaš u zasebnu datoteku, a mislim da sam baš tebi ne tako davno napisao da se previše zamaraš brojem zapisa u bazi, a premalo samim dizajnom baze. Dobro dizajnirana baza i aplikacija koja je koristi nema problema ni sa par desetaka milijuna zapisa, a da bi imala sa 500tinjak tisuća.
Kako ti je CC rekao - vrlo je pogrešno razbijati si glavu stvarima koje ne možeš znati. Posveti se dizajnu baze, a tek kasnije, kada je stvar napravljena, vršiš “profiliranje”, tj. određuješ gdje se stvarno nalaze uska grla (koji upiti troše najviše vremena i zašto). Uzorka uskog grla i rješenja tada može biti jako puno.
Ovako načelno rečeno, odgovor glasi: NE, sasvim sigurno dijeljenje u više tablica neće “ubrzati” ništa. Jer da bi, onda bi to pisalo u uputama za korištenje baze. Pa pogledaj tamo i vidi spominje li se nagli pad performansi u nekim situacijama i kojima.
Jednostavno rečeno - razmišljaš o krivim stvarima u krivo vrijeme.
naravno da sve stavi u istu tablicu, pazi se na tip tablica, neke ne podrzavaju citanje i zapisivanje u istom trenutku vec lockaju thread dok ne obave posao…
kao sto su ti rekli, prvo si dizajniraj tablicu, tj strukturu tablice, a onda dalje razmisljaj… naravno kad dizajniras bazu i tablicu odmah dizajniraj i klasu za istu…
[quote=“tsereg”]Kako ti je CC rekao - vrlo je pogrešno razbijati si glavu stvarima koje ne možeš znati. Posveti se dizajnu baze, a tek kasnije, kada je stvar napravljena, vršiš “profiliranje”, tj. određuješ gdje se stvarno nalaze uska grla (koji upiti troše najviše vremena i zašto). Uzorka uskog grla i rješenja tada može biti jako puno.
Ovako načelno rečeno, odgovor glasi: NE, sasvim sigurno dijeljenje u više tablica neće “ubrzati” ništa. Jer da bi, onda bi to pisalo u uputama za korištenje baze. Pa pogledaj tamo i vidi spominje li se nagli pad performansi u nekim situacijama i kojima.
Jednostavno rečeno - razmišljaš o krivim stvarima u krivo vrijeme.[/quote]
Vodio sam se onim da je bolje spriječiti nego liječiti
Baza će biti dosta velika i konstantno će rasti, a podaci iz nje će se upotrebljavati za grafičku analizu (crtanje dijagrama i slično u PHP-u). Iz toga slijedi ta “ideja”, ako je potrebno iscrtati dijagram sa 3 parametra o Objektu br. 5, da je puno brže dohvatiti te podatke iz tablice koja sadrži 40t redaka nego li iz tablice s 10-20 puta više redak.
Razlozi tvog razmišljanja (“bolje spriječiti” i “brže je dohvatiti”) su ispravni. I slobodno tako razmišljaj i utroši vrijeme kako bi postigao ubrzanje i uštedu vremena. Naši se komentari ne odnose na to, već na jedan drugi aspekt koji ću ti pokušati ilustrirati.
Kada imaš dobar indeks - to znači da polje po kojem dohvaćaš zapis u bazi podataka ima uniformno distribuirane vrijednosti po cijelom opsegu mogućih vrijednosti - onda će pretraživanje tablice za adresiranim zapisom biti izvredeno u najviše log2(N) koraka, gdje je N broj zapisa u tablici. Dakle, za tablicu od 40.000 zapisa će sustav za upravljanje bazom podataka morati s diska očitati najviše 15 zapisa da bi našao traženi, a za tablicu s 20x više zapisa (800000) će morati očitati najviše 19 zapisa.
Ove vrijednosti predstavljaju procjenu kompleksnosti dohvata i smislene su u svrhu međusobne komparacije (ne u smislu procjene stvarnog vremena trajanja dohvata u milisekundama ili sl. iako će korelacija postojati).
Sada si ti sam procjeni koliko je isplativo potrošiti sat svog vremena da pripremaš svoj program tako da može raditi s više tablica, a koliko je isplativo potrošiti sat vremena da projektiraš dizajn kako bi dobio dobre podatke za indekse i onda optimizirao njih.
S druge strane, ako imaš loše izabrani indeks, onda će u najgorem slučaju morati očitati 40000 ili 800000 zapisa, pa se postavlja pitanje… pogodi čega… čekaj… pogodio si: dizajna baze.
Uoči da u samom DBMS-u imaš puno više značajki koji se bave indeksima, a jako malo ili nimalo značajki koje se bave distribucijom podataka po više tablica. To ima razlog. Zato općenito vrijedi pravilo: go with the flow.
[quote=“tsereg”]…
Kada imaš dobar indeks - to znači da polje po kojem dohvaćaš zapis u bazi podataka ima uniformno distribuirane vrijednosti po cijelom opsegu mogućih vrijednosti - onda će pretraživanje tablice za adresiranim zapisom biti izvredeno u najviše log2(N) koraka, gdje je N broj zapisa u tablici. Dakle, za tablicu od 40.000 zapisa će sustav za upravljanje bazom podataka morati s diska očitati najviše 15 zapisa da bi našao traženi, a za tablicu s 20x više zapisa (800000) će morati očitati najviše 19 zapisa.[/quote]
Zahvaljujem, ovaj dio mi je zapravo pomogao… Samo bih te zamolio više informacija o “dobrom indeksu” ili nekakav izvor koji preporučuješ…
U ovoj bazi recimo često će se pretraživati po datumu, da li je to onda “dobar indeks”, ili sam fulao poantu?
Dobar indeks je upravo onaj po kojem najčešće vršiš pretraživanja. To su vrijednosti po kojima se zapisi mogu sortirati radi bržeg pretraživanja (primjene binarnog algoritma). Ali uoči: ako je to stvarno datum, onda teorijski možeš imati situaciju da u istoj godini (365 različitih vrijednosti) imaš više desetaka tisuća zapisa. To znači da imaš puno ponavljajućih vrijednosti. Očigledno, datum bi mogao biti jedna od komponenti indeksa.
Indeks može biti dobar za jedan upit, a loš za neki drugi. Poanta je da se izbjegne sekvencijalno pretraživanje (skeniranje zapisa ili podskupa zapisa).
Izbor indeksa ovisi o upitima koje ćeš postavljati. U svrhu analize efikasnosti upita DBMS-ovi imaju neku naredbu ili drugačiju mogućnost ispisavanja plana izvođenja upita. Npr. naredba “EXPLAIN” ili “DESCRIBE” ili sl. Čak i u Accessu možeš doći doći do ovog plana ukoliko aktiviraš određenu opciju u registryju.
Što se literature tiče, nemam što za preporučiti osim nešto poput ovog:
[quote=“TomislavS”]U vidu brzine dohvaćanja i obrade podataka iz MySQL baze podataka zanima me ima li smisla podijeliti jednu tablicu (Objekti) u n identičnih?
Tablica Objekti:
+---------------
| - ime
| - vrsta
| - polje1
| - polje2
| ...
+---------------
** uoči polje "vrsta"
Unutar prethodne tablice će u startu biti 500 000+ zapisa, te uz dnevno povećanje od cca 200 zapisa.
Ukoliko bi tu tablicu podijelio u 10ak manjih (onoliko koliko ima vrsta objekata):
Na ovaj način bi svaka tablica u početku imala oko 40 000 rezultata, te 15ak novih dnevno.
Da li je ovo potrebno? Do kolikog broja zapisa program ne bi trebao “zapinjati”?
(pod pretpostavkom da će program koristiti najviše do 100 ljudi istovremeno)
p.s.Izrada priručne memorije nije opcija jer postoji velik broj varijabli kod pretraživanja, a nema određene kombinacije koja se najčešće ponavlja…[/quote]
optimiziras prema webu ? U pocetku nakrcas sve u jednu, nakon toga napises
kod koji kreira zasebnu sa npr. 1000 koje se stalno vrte + ostatak ( razlomis u 2 baze ),
nakon toga ovaj ostatak po nekom zasebnom necem razlomis u x po frekvenciji
ili necem trecem itd. Logove koristis za sto ti vec trebas a kod sam odrzava i
optimizira. Hijararhija podataka
[quote=“ninohr”]optimiziras prema webu ? U pocetku nakrcas sve u jednu, nakon toga napises
kod koji kreira zasebnu sa npr. 1000 koje se stalno vrte + ostatak ( razlomis u 2 baze ),
nakon toga ovaj ostatak po nekom zasebnom necem razlomis u x po frekvenciji
ili necem trecem itd. Logove koristis za sto ti vec trebas a kod sam odrzava i
optimizira. Hijararhija podataka[/quote]
To je loše treba kako su gore kompetetniji ljudi od mene rekli napraviti dobre relaciji i dobro relaciono povezati baze samim time se u startu mogu eliminirati dupli unosi, a smo pretraživanje baze je puno lakše. Ak sam šta krivo naveo nek me isprave gore kopetentije kolege
[quote=“ninohr”]optimiziras prema webu ? U pocetku nakrcas sve u jednu, nakon toga napises
kod koji kreira zasebnu sa npr. 1000 koje se stalno vrte + ostatak ( razlomis u 2 baze ),
nakon toga ovaj ostatak po nekom zasebnom necem razlomis u x po frekvenciji
ili necem trecem itd. Logove koristis za sto ti vec trebas a kod sam odrzava i
optimizira. Hijararhija podataka[/quote]
Kaj si ti tu nadrobio vjerojatno niti sam ne znaš.
[quote=“TomislavS”]Zahvaljujem, ovaj dio mi je zapravo pomogao… Samo bih te zamolio više informacija o “dobrom indeksu” ili nekakav izvor koji preporučuješ…
U ovoj bazi recimo često će se pretraživati po datumu, da li je to onda “dobar indeks”, ili sam fulao poantu?[/quote]
Donekle si pogodio, a donekle i fulao poantu. Zato ti kažem da je bitno znati zašto, kako i gdje će se koristiti baza. Ukoliko tražiš po datumu i samo po datumu onda da ali ako tražiš i po drugim uvijetima onda ne. Ukoliko uključiš još jedno polje za pretragu trebao bi jedan kompotizni index, odnosno index koji se sastoji od više polja, a poredak tih polja u tom indexu opet ima ulogu koliko će polja ta pretraga počešljati. Imaš tablicu sa poljima npr. Id, Ime, Datum, NekoPolje i kompozitni ključ [Ime, Datum]. Ukoliko ti je glavni kriterij pretrage datum ovaj index neće biti efikasan kao što bi bio kada bi u tom indexu datum zauzimalo prvo mjesto. Dizajn, optimizacija i održavanje baze je dosta složena materija.
Preporučam ti da počneš s nečim ovakvim: Fundamentals of Relational Database Design Relational Database Design Basics | Database Solutions for Microsoft Access | databasedev.co.uk Relational Database Design
(itd, “database desing basics” ili “database design fundamentals” su dosta dobri pojmovi koji će te uvesti u taj svijet)
i da se u startu ne zamaraš previše sa količinom podataka koji će biti pohranjeni u bazi, jer je vrlo vjerojatno nećeš niakada napuniti tolikom količinom podataka da bi ti baza stvarala problem u brzini aplikacije.
Spomenuo si crtanje grafova itd. To je stvar aplikacije, a ne baze podataka, jednom kad si dohvatio podatke iz baze sve ostalo je na aplikaciji i na njenom optimiziranju, a n e na bazi podataka.
ajde molim te jos jednom jer nisam razumio : kako moze znati relacije,
povezivanje, strukturu podataka, tip podataka i slicno ako ne radi
zivotno sa bazom ?
ja ne placam tvoje drobljenje i reprodukciju znanja iz knjiga kao sto nisam
kriv za tvoj prkos i bijes pa bi te molio da u buducnosti zaobidjes bilo sto
moje napisano
[quote=“ninohr”]ajde molim te jos jednom jer nisam razumio : kako moze znati relacije,
povezivanje, strukturu podataka, tip podataka i slicno ako ne radi
zivotno sa bazom ?[/quote]
Kao prvo fino si me nasmijao.
kao drugo kak bi ti to napravio bez baze?
Relacije neznaš one proizlaze iz same analize problema, a ako nisi tolko dobar sa bazom imaš programe za to. Prvi mi pada na pamet Workbench imaš ga za skinut na mySQL stranici. Možda ni naj bolji no besplatan je.
[quote=“ninohr”]ja ne placam tvoje drobljenje i reprodukciju znanja iz knjiga kao sto nisam
kriv za tvoj prkos i bijes pa bi te molio da u buducnosti zaobidjes bilo sto
moje napisano
Hvala[/quote]
Gle postavljaš malo preopća pitanja za koje ne postoji drugi odgovor do reference na knjigu. Ja nisam tolko dobar u bazama ko kolege gore no znam u njima napravit kaj mi treba.
