ovo ne valja koliko ja vidim
tj prethodna, trenutna i buduca lokacija - kakve to veze sa bilo cim ima? otkud ti u pracanje id znas de ce da bude uredjaj sutra i kod koga je bio juce ...

imas uzeo mika 10.jan do 15jan i odneo u zimbabwe ... onda imas uzeo joca 16jan do 25jan i odneo u priboj .. sortiras po tim datumima da vidis "de je bio" .. de ce biti gledas iz rezervacija ..

pogledaj po netu ima tih "bibliotekarskih" modela dosta pa iskopiraj jedan od njih

Evo gledao sam te modele biblioteka. Cak sam skinuo jedan kompletan model odavde
http://www.elitesecurity.org/t337481-3
Ali ne nalazim puno slicnog, jer u cemu je razlika.
Ti kad iznajmis knjigu taj koji je iznajmljuje on dodje i uzme knjigu i odmah se i zna da je on odmah odgovoran za knjigu i lokacija nek bude njegova adresa sada i to je to, nema izmedju nista.
A kod ovog trekera nije tako.
Ako na primer uredjaj iz Beograda se prijavi za Indiju.
Taj iz Indije ne dolazi i ne preuzima uredjaj vec ga jedno lice prenese od Beograda do Londona i on je odgovoran za uredjaj, pa od Londona do na primer do Amerike drugo lice pa je ono odgovorno za uredjaj, pa tek onda trece lice ga nosi u Indiju i ono je odgovorno, i tek onda ga to lice iz Indije preuzima i to je kraj putovanja.
Pa posle nekoliko dana se opet uredjaj prijavljuje za drugo mesto i opet krece promena polozaja.

Mene je sve mnogo zbunilo jer ima dosta situacija.
Pa ne znam koji je najbolji nacin da napravim strukturu baze. Jer moram da imam i istoriju kretanja, jer ako neko nesto zezne da uvek mogu da vidim kod koga je sve bio uredjaj, tj istoriju kretanja uredjaja.

Tako da ovaj model biblioteka ne koristi mnogo.

isti je model kao biblioteka samo nemas vracanje .. uredjaj je "kod nekoga" dok ga neko ne preuzme .. i imas dodatno adresu ..

cela fora u tvom modelu koja je problematicna je "prethodna" i "sledeca" adresa .. u najboljem slucaju tu mozes da imas prethodnu adresu koja je u stvari id sloga iste te tabele

Ne znam koliko je dobra ideja da tabele uredjaj i pracenje spojim u jednu tabelu
a da imam dodatnu tabelu istorijau kojoj bi nakon svake promene cuvao podatke o lokacijama tipa:
Tabela: Istorija
Istorija_ID
Uredjaj_ID
Lokacija
Odgovorni
Datum
Opis izmene(na pr. uredjaj je u putu, uredjaj je stigao, uredjaj je prijavljen)

Mozda bi mi ovo i ubrzalo jer nemam joinovanje tabela?
Ili je ovo mozda glupa ideja?

Da, prethodna lokacija je trenutna lokacija od prethodnog zapisa.
Ali kako da napravim ja upit u kom imam listu uredjaja i podatke, gde je bio, kod koga je bio, gde je sada, kod koga je sada, i gde ce biti i kod koga (ako se to zna), i da li je mozda neko rezervisao.
Deluje skroz jednostavno ali nije bas zbog ovog upita. Jer zahtev je takav da svi ovi podaci moraju da se prikazu kao jedna tabela na stranici.

Treba da samo vidis listu uredjaja i sve ove podatke.

A to meni model biblioteke ne omogucava.

Ja tamo mogu da vidim samo kod koga je knjiga, a meni treba i kod koga je bila i da li ce ici kod nekoga i da li se mozda neko prijavio da je uzme sve na jednoj strani.

jedan upit je gde je sad, drugi je gde je bio a treci je "istorija" sa i gde je sad i gde je sve bio .. (select lokacija ... order by datum) mozes tu da sortiras naopako pa da uradis limit 2 i da uzmes "sad i juce" varijantu .. ne vidim gde je problem ...

uzmi workbench i nacrtaj bazu bice ti lakse

Model biblioteke koji si pomenuo sam ja radio i mislim da ne možeš kopi/paste da odradiš nisu isti problemi ali može da ti posluži kao osnova. U principu ovaj deo oko iznajmljivanja bi trebalo da je isti. Samo što za tu tabelu u koju stavljaš iznajmljivanja treba da vežeš jednu tabelu koja će sadržati listu ovih odgovornih lica. Znači tabela IZNAJMLjIVANjE je u relaciji 1 prema više sa tabelom recimo ODGOVORNI. Samo dajem ideju. Dobro ti je rekao Bogdan skiciraj ove tabele u Workbenču da bi mogli lakše da pratimo, ovako se pogubi čovek među tabelama, naporno je čitati sav taj tekst.

evo ljudi.
Ja sam stvarno uradio koliko znam, i stvarno mi treba pomoc za dalje.
Nisam neki strucnjak za baze, ali upite kao ovo stvarno ne znam kako bih napravio.

Ja sam evo napravio strukturu i uvezao tabele.
Napravio sam neki polovican upit

Ali nema sve ono sto meni treba

Znaci meni treba upit koji ce da mi vrati listu uredjaja sa podacima, trenutna lokacija tipa(Srbija-Beograd), trenutno odgovorno lice(tipa Miodrag Lapcevic)
podatke gde je uredjaj prethodno bio tipa, prethodna lokacija(tipa Srbija-Novi Sad), prethodni odgovorni (tipa Petar Petrovic)
podatke ako je prijavljen uredjaj za putovanje, sledecu lokaciju(ali tipa Srbija-Beograd), ko preuzima uredjaj(tipa Miodrag Lapcevic), datum kad stize, i lic akoji transferuju uredjaje ali kao jedno polje kao string, tipa Miodrag Lapcevic, Bogdan Kecman
podatak da li je uredjaj rezervisan u trenutku izlistavanja uredjaja(tipa jeste ili nije)

E sad ja stvarno nisam nikako sve ovo uspeo da uklopim u jedan upit, a meni treba bas jedan upit i koji nece sporo da radi.
Attachovao sam bazu koju sam napravio i sliku dijagrama, i dijagram. Ja sam koristio Manager za Mysql.

Ako moze savet sta da uradim i da li sam dobro napravio strukturu sada, i kako da napravim ovaj komplikovani upit.

Upit:

Medjutim ovo nista ne valja. Bas nista mi ne vraca, a i nema ostale podatke koje mi fale

ruzan ti ovaj diagram, u cemu si ga crtao ...

elem, par pitanja da bi svatio logiku ove seme

1. sta je
- uredjaj.grad
- uredjaj.lice

2. zasto "transfer" nije samo jedna od "akcija"?

Evo ovako.
1. Lokacija nekog uredjaja treba da bude u formatu Drzava-Grad, na primer Srbija-Beograd, ili Francuska-Pariz
Pa sam ja da bi sve bilo kako treba napravio tabele Drzava i tabele Grad. I sada za umesto ranijeg polja lokacija koja mi je bilo string tipa, ja sam zamenio da to bude ID Grada i na osnovu toga izvlacim podatak o lokaciji. Koja je drzava i koji je grad jer u tabeli grad imam ID Drzave

Isto tako sam sada za podatak odgovorno lice, koje sam ranije cuvao kao string napravio sam posebnu tabelu lice u kojoj je lista svih lica koja mogu da koriste i transferuju uredjaje. I sada umesto ranije kao odgovorno lice za uredjaj sto mi je bio string tipa Miodrag Lapcevic ja sada cuvam id lica iz tabele lice. I na osnovu toga treba da izvucem iz tabele lice Ime i Prezime

2. E sad sta je transfer? u tabeli transfer su lica koja ce sve transportovati uredjaj na njegovom putu i to se unosi prilikom prijave.
Na primer uredjaj se transferuje od Beograda do Londona.
I admin kad prijavljuje uredjaj na putovanje on unese lice koje ce ga prevesti od Beograda do Novog Sada, zatim lice koje ce ga Preneti od Novog Sada do Frankfurta. I onda lice koje ce ga preneti od Frankfurta do Londona..
To su znaci tri lica. Zato imam posebnu tabelu transfer gde se uvezujem id prijave sa id lica koja su zaduzena za transfer.

3. Ja za MySql koristim EMS Menager Fro MySql 2010 http://www.sqlmanager.net/en/products/mysql/manager
Nije lose ima dosta opcija za rad sa bazama.

3. odlican je EMS, jedino je malo skup a ERD tool mu je malo ruzan :D

2. opet je pitanje zasto transfer nije akcija

na primer u tabeli sa akcijama imas nesto tipa

preuzeo mika petog februara radi transfera za stutgart,
preuzeo zika sedmog februrara radi transfera za mumbasu
preuzeo ngoma drugog marta radi transfera za najrobi
pruzeo dzamburu petog marta radi koristenja u najrobiju
preuzeo gnomokuci desetog juna radi transfera za hong kong
...

dakle transfer je akcija kao svaka druga. podaci o tome gde ti se trenutno nalazi i gde se istoriski nalazio uredjaj se svi nalaze u jednoj tabeli .. da li je bio "na putu" ili je bio "u uporabi" razlikuje se po action_id

1. taj deo je ok, taj koji spominjes, pitanje je zasto u toj tabeli

Tabela Akcija je samo sifarnik i ja sam tu samo sam izdvojio ono sto mi je ranije bilo string, u stvari akcija sluzi da samo opise u tabeli istorija sta se desilo tog datuma.
E sad zasto transfer ne moze da se cuva u istoriji, ne moze jer se transfer zadaje pre nego sto se neki uredjaj krene na putovanje.
Evo da ti bude jasnije dacu ti primer kako sve funkcionise.

Imas na primer uredjaje Uredjaj 1, Uredjaj 2, Uredjaj 3.
Imas korisnike(lica) Miodrag Lapcevic, Bogdan Kecman, i Petar Petrovic, Pera Peric od kojih je Miodrag Lapcevic Admin.
I imas drzave u kojima ce ici uredjaji i gradove na primer, Srbija, Francuska... I gradove Beograd, Novi Sad... za Srbiju i za Francusku Pariz...

E sad ja kao admin se nalazim u Beogradu i ja otvorim aplikaciju i dodam prve uredjaje, Uredjaj 1, 2, i 3. I njihova trenutna lokacija je Srbija-Beograd i Odgovorno lice je Miodrag Lapcevic. Znaci ja upit kad se izvrsi trebao bi da vrati ovo
Uredjaj | Prethodna Lokacija | Prethodni Odgovorni | Trenutna Lokacija | Trenutno Odgovorni | Sledeca Lokacija | Sledeci Odgovorni | Datum kad treba da stigne | Lica za transfer | Datum poslednje izmene | Status | Rezervisan
Uredjaj 1 | ----- | ------ | Srbija-Beograd | Miodrag Lapcevic | ---- | ------- | --------- | ----- | 14. jul 2011. 08:45:45 | Dostupan | Nije

E sad taj uredjaj treba da ide za Frnkfurt i ja kao admin otvorim formu sa prijavu uredjaja za putovanje i tu selektujem drzavu i grad gde uredjaj putuje na pr Francuska-Pariz, selektujem datum kad treba da stigne urdjaj u Pariz na pr 23. jul 2011. 12:00:00
I selektujem lice koje treba da preuzme uredjaj, na primer Pera Peric
I kljucno, ja selektujem u listi lica koja ce biti zaduzena za transport i tu selektujem Bogdan Kecman i Petar Petrovic
I upit treba da vrati ovo:
Uredjaj | Prethodna Lokacija | Prethodni Odgovorni | Trenutna Lokacija | Trenutno Odgovorni | Sledeca Lokacija | Sledeci Odgovorni | Datum kad treba da stigne | Lica za transfer | Datum poslednje izmene | Status | Rezervisan
Uredjaj 1 | ----- | ------ | Srbija-Beograd | Miodrag Lapcevic | Francuska-Pariz | Pera Peric | 23. jul 2011 12:00:00 | Bogdan Kecman, Petar Petrovic | 14. jul 2011. 09:15:45 | prijavljen | Nije


E sad sledeci dogadjaj je da Bogdan Kecman koji prenosi uredjaj od Beograda do Novog Sada preuzme uredjaj od mene i ti se ulogujes u program i prijavis da je uredjaj kod tebe i da ga vozis za Novi Sad
Uredjaj | Prethodna Lokacija | Prethodni Odgovorni | Trenutna Lokacija | Trenutno Odgovorni | Sledeca Lokacija | Sledeci Odgovorni | Datum kad treba da stigne | Lica za transfer | Datum poslednje izmene | Status | Rezervisan
Uredjaj 1 | Srbija-Beograd | Miodrag Lapcevic | na putu | Bogdan Kecman | Francuska-Pariz | Pera Peric | 23. jul 2011 12:00:00 | Bogdan Kecman, Petar Petrovic | 15. jul 2011. 09:15:45 | Na putu | Nije

(*) Ovo cu resiti tako sto cu ukoliko je status uredjaj "na putu" programski umesto lokacije ispisati na putu
Rezervisan to se izvlaci iz tabele Rezervicija i pokazuje d ali je u trenutku izvrsavanja upita rezervisan

E sad ja pri svakom ovom preuzimanju U tabelu Istorija unosim promene
Da bih imao istoriju svih preuzimanja i dogadjaja z akoje treba mi drugi upit ali za to bih znao da odradim

Eto to je logika programa.

Nije nimalo lako da se napravi jedan upit koji sve vraca

kad kazem akcija mislim na tabelu "istorija" ...

elem, i dalje mislim da sve treba da bude i toj jednoj tabeli samo sa razlicitim action_id ... abitno da li se to vec desilo ili tek treba da se desi i abitno da li je uredjaj u tranzitu ili je uredjaj na koristenju, podaci su isti, razlikuje se samo action_id

sto se tice "jednog upita", zasto mora izvestaj da se generise jednim upitom, generisi ga sa 101 upitom kakve to veze ima.. bitnoi je da tih 101 upita budu "pravi" i "kako valja" ... mnogo bolje 101 kratak upit koji koristi indexe nego 1 upit koji radi full table scan join kroz 44 tabele

Mislis da mi ne treba tabela prijava, vec da sve stavimu tabelu istorija. ALi kako cu da u tabeli istorija sacuvam 5 lica koja su zaduzena za transport.
Ok, mogu ja i da napravim 2 upita da mi vrati ovo, ali bitno je da to radi brzo jer tih uredjaja ima oko 15000 i svaki dan se tranportuje bar 40%.

Jel imas neki link za MySql indeksiranje da konacno pohvatam sta i kako da indeksiram. Iskreno ja nemam pojma o indeksiranju. kopam po netu i snalazim se nesto.
Evo sad sam opet kopao ali nista da kazem dobro nisam nasao.
Na primer ova tabela Uredjaj ima jso 20 polja o podacima za uredjaj tiba, sifra, broj, PIN ...
I sva ta polja se pretrazuju. Za vecinu sam stavio da u varchar tipa. E sad jel ispravno da stavim da je za svako to polje da stavim Fulltext indeks?
Mada sam vidoe d aje po tabeli maksimalno dozvoljeno 16 u ovom EMS Manageru?

ja bi to sve stavio u tabelu istorija (verovatno bi je drugacije nazvao) i pritom bi dodao neki tinyint(1) koji bi definisao da je "ceo proces gotov" a onda particionisao tabelu po tom polju tako da imas realno 2 particije, "istoriju" i transakcije koje su u toku tako da ti upit iz ove "aktivne" particije ide super brzo, a imas istoriju kada ti zatreba




to je sve jedna "transakcija" da to tako nazovem, svako od tih lica je razlicita akcija .. imas recimo akciju "treba da preuzme" tako da imas datum kada pera treba da preuzme device, onda kada ga preuzme to prebacis u akciju "preuzeo za transport" ili "preuzeo za koristenje" ..

generalno stvari iz buducnosti mozes da drzis u nekoj posebnoj tabeli (slicnog formata kao ova) pa da onda iz te tabele brises i guras u ovu .. mada obzirom da je format vise manje isti nema razloga da ne sedi u istoj tabeli

Jedno pitanje.
Da li je dobro da na polje Datum poslednje izmene koje se automatski updejtuje pri svakoj promeni stanja stavim index jer ce se po njemu cesto vrsiti pretraga?

Resio sam da sva ova polja Prethodna lokacija, Prethodni odgovorni, Trenutna Lokacija, Trenutni Odgovorni, Sledeca lok, Sledeci odg, strpam u tabelu uredjaj a u tabeli istorija cuvam svaku izmenu.
Znam da nije dobro normalizovano, i da ce se podaci duplirati ali ovako ce najbrze raditi

datum index - naravno
duplikati nisu pretarano problematicni - postavi erd novog modela

Evo ga dijagram.
opet sam vratio da mi lokacija bude string posto cu u programu odraditi da se drzava i grad biraju, tako da nece dolaziti do greska, a nazivi drzava i gradova mislim da se nece menjati :)
E sad isto sam uradio za lica, izbacio sam da mi korisnik bude id iz tabele korisnika, posto svaki korisnik ima jedinstveno krace ime pa se umesto id-ija korisnika sada u tabelu za odgovorno lice upisuje to krace ime od tri karaktra.
Pa to prikazujem umesto imena i prezimena, a da kraca imena se isto nikad ne menjaju. Sto se tice istorije o cemu se tu radi. Ja tu upisujem sve podatke koji su vezani za pracenje cim se desi neka promena, tako imam kompletnu istoriju, posto s etako i trazi.
Eto to je to

Da li ima razlike u izvrsavanju upita, tj da li uopste ima razlike izmedju ova dva upita:

i ovog

mislim da si preterao sa denormalizacijom al ..

sto se tice upita, isti su, kad nisi siguran uradis explain jednog i drugog i uporedis rezultat explain-a, ako je isti - to je to

Jbg. Moram da zavrsim strukturu baze i samu bazu, da bih nastavio program, tri dana sam crtao i dijagrame i razmisljao sta mi je najbolje ali mislim da sam ovako dosta smanjio upit i JOINOVANJE evo sad izgleda ovako:
I generalno brzo radi 78ms. mislim da je to ok


E sad mozda ovaj upit moze jos bolje da se optimizuje, da na neki nacin izbegnem ovolike LIKE-ove. Ali sam stavio da su mi sve tabele innoDB tako da ne znam drugaciji nacin da pretrazim sva polja u tabeli za zadati kriterijum pretrage.

kao sto rekoh vec mnogo puta like % je smrt - to je full table scan obavezno, to je 70ms sad, za 2 meseca ce biti 10sekundi za godinu dana ce prsnuti server ...

1.normalizujes
2.ako moras uradis like % iz "malih" tabela i onda napravis upit sa tim id-ovima iz "velike" tabele, like % iz tabele od preko par stotina entrija je znak da si nesto gadno zabrljao


dalje eqdb_device.Status_ID LIKE '%a%' .... kako ovo moze da bude like ? status_id je valjda numeric .. zasto like? znas da mozes da imas 5 statusa ..

etc etc ... kao sto rekoh, ne valja, imas dovoljno informacija da znas sta treba da uradis, ostaje samo da se to uradi i to je cca 30min posla max

Cek ovo te nisam razumeo

2.ako moras uradis like % iz "malih" tabela i onda napravis upit sa tim id-ovima iz "velike" tabele, like % iz tabele od preko par stotina entrija je znak da si nesto gadno zabrljao

Meni se u programu trazi da pretrazim sva polja tabele za zadatu rec, jedino da napravim novo polje u bazi tipa keywords pa da u njega strpam vrednosti svih polja i onda samo za to polje uradim LIKE
Jer ja ovde samo pretrazujem tabelu eqdb_device.

A ovo za int cu srediti

select * from velikatabela where grad_id in (select grad_id from grad where grad_name like %) or user_id in (select user_id from user where user_name like %) ...
...

mnooogo brze od toga sto si ti napisao (ni ovo nije idealno resenje)

generalno ako imas non stop zahtev da pretrazujes sva polja moras da pravis recnik i index

inace to u 99.9% slucajeva znaci da onaj ko dizajnira aplikaciju (to u ovom slucaju nisi ti nego klijent) nema pojma sta oce

He, he...
Pa o tome ti pricam. Ja sam dobio zahteve i na meni je da najbolje realizujem. Napravio sam indexe, a dodacu jedno polje u kom cu cuvati kljucne reci za pretragu pa cu samo njega pretrazivati.
U svakom slucaju dosta si mi pomogao, stvarno sam pohvatao dosta stvari iz ovih poruka.
Hvala puno

uvek je smor kada klijent nema pojma sta hoce a ti nemas autoritet da mu kazes da prvo smisli sta hoce pa tek onda dodje sa zahtevima ... na zalost to nam se svima desava non stop i od toga ne moze da se pobegne...

ja sam na par mesta seljacima radio seljacko resenje ... napravis lepo celu bazu kako treba, innodb, transakcije, referencijalni integritet ovo ono i stavis jednu tabelu koja je myisam koja ima id int, seljana varchar(1000) .. i onda na varchar polje stavim full text key i te debilne pretrage rade kroz taj myisam ..

kada za takvu pretragu stvarno ima potrebe onda napravis svoj lokalni index - dakle pravis recnik + reference i to je to

Ma da tako je najbolje.
Nego znas sa cim sad imam problem. Kad mi se izvrsi upit bez ORDER BY traje mi 78 ms. Sto je super brzo, ali cim stavim ORDER BY po nekoj koloni onda mi traje upit 2,5 sekundi. Sto je strasno sporo, da ne poverujes. I evo sad se mucim sa tim.
Pa sam onda uzeo pa sam izbacio ORDER BY u mysql-u vec sam napravio sortiranje programski u php-u. Kad mi vrati upit rezultat ja ga presortiram i ispisem. Medjutim sta je sad problem, ja mogu da presortiram na taj nacin samo limitirani niz ne mogu sve rezultate.

Tako da opet moram da vratim ORDER BY. Pa sad evo kopam po netu da vidim sta da radim da ubrzam ovo.

pogledaj sta kaze explain, verovatno radis full table scan a imas limit, kada uradis full table scan sa npr limi 10 on prolazi kroz tabelu dok ne nadje 10 i to je to, kada imas order by, on mora da prodje CELU tabelu pa onda da sortira rezultat pa ti vrati 10kom

Pa jeste tako je. Ja imam LIMIT 0, 500.
I kad imam ORDER BY on prvo sortira sve rezultate pa uzme prvih 500.
E ne znam sta da radim, bez ordera ne mogu a on mi mnogo, mnogo usporava upit

resenje je vrlo jednostavno - popravi upit tako da ne radi full table scan :)

pa to je nemoguce.
Jer pazi kako radi program, ti kad se ulogujes program prikazuje listu svih uredjaja.
Naravno prikaze 10 uredjaja sortiranih po datumu poslednje izmene i imas boks za paginaciju da mozes da kazes ledecih 10 i tako redom.
E tek onda postoji polje za pretragu gde kucas kljucnu rec i pretrazi se lista svih uredjaja.
Sve ovo ukazuje da ja na pocetku moram da imam ORDER BY cele tabele, i da ne moze da se izbegne

order by cele tabele nije problem ako je order po indexiranom polju dakle ako imas

create table t1 (i int primary key not null, j int, a varchar(100), b varchar(100), key i_j (j), key i_a(a), key i_b (b));

i onda uradis

select * from t1 order by a limit ..

to nije full table scan i nece da traje sto godina ...

naravno ako tu ubacis where b like %xx% onda to jeste full taqble scan i onda si usr* motku ali mislim da sam ti vec 3 puta rekao kako da izbegnes taj table scan pa necu vise da se ponavljam