[ Man-Wolf @ 24.04.2009. 00:51 ] @
Pozdrav,

Prvo bih zeleo da se izvinim ukoliko je naslov teme ne odgovarajuci, ali stvarno nisam imao drugu ideju ...

Naime, sledi problem - Radim na projektu koji se bavi, aj da kazem - "spajanjem" - modela (manekena, whatever,...) i modnih kuca, fotografa, ... Na sajtu se svako moze registrovati ili kao model (maneken) ili kao rekruter (modna kuca, fotografi, .....). E sad, treba da uradim sledece - da svaki model moze da pozove rekrutera (ili obrnuto - rekruter da pozove modela) da odrade poslic (slikanje, je**nje, whatever - ne ulazim u to ) ). Forma za postavljanje ponude sadrzi sledeca polja:

1. Cena (promenljiva)
2. Mesto (promenljivo)
3. Datum (promenljiv)
4. Komentari/Detalji (fiksno i manje vise ne bitno za moje pitanje)

I znaci, ako recimo ja zelim da pozovem nekog modela da odradimo slikanje, ja popunim tu formu i njemu stigne pozivnica. Ee sad, ono sto meni predstavlja problem jeste to sto model koji je pozvan da radi, moze da zatrazi izmenu nekih podataka. Na primer: Modelu ne odgovara cena (oce vise para) ili datum i onda on/ona treba da unese neko drugo vreme/cenu. Pa onda, ja (koji izigravam fotografa u ovoj prici), necu da prihvatim njenu cenu nego nadjem neku zlatnu sredinu. Takodje i datum moze da se menja (zato sam i naveo u spisku gore - promenljiv - znaci, druga strana uvek ima mogucnost da trazi neku drugu cenu/mesto/datum, ....). I tako to moze da se vrti u krug, sve dok se obe strane ne sloze oko detalja ....

Meni je problem upravo u tim izmenama, tj. bolje receno - kako organizovati polja/tabele u bazi, kako bi se omogucile ovakve "manipulacije" (stvarno nisam znao kako drugacije da se izrazim )? Ja imam neke ideje i trenutno ih "bacam na papir", pa cu cim zavrsim da okacim ovde u vidu PDF dokumenta, pa da vidim sta vi mislite o tome. Medjutim, u medjuvremenu, ako neko ima bilo kakvu ideju, zamolio bih ga da je iznese

P.S. Ukoliko sam previse konfuzno pisao, ili neki detalji nisu jasni, slobodno pitajte, nemojte da se stidite )

Unapred zahvalan,

Mihailo Joksimovic

EDIT: Evo okacimo sam PDF fajl koji, nadam se, jasno opisuje kako sam zamislio da organizujem bazu. Btw, nisam napomenuo (a mozda ce nekog da zanima - sa serverske strane se koristi PHP)

[Ovu poruku je menjao Man-Wolf dana 24.04.2009. u 02:16 GMT+1]
[ bogdan.kecman @ 24.04.2009. 13:17 ] @
Skines MySQL Workbench: http://dev.mysql.com/downloads/workbench/5.1.html

I krenes polako da crtas to sto si napisao. Kada zaglavis (ne znas kako dalje), pogledas prvo: http://www.elitesecurity.org/t...QL-dizajn-za-bolje-performanse
pa onda pitas ovde pritom zakacis snapshot iz workbench-a da vidimo dokle si stigao. Ovako sa "jel moze neko umesto mene" niko nece preterano da se iscima da ti izprojektuje bazu od pocetka ..
[ Man-Wolf @ 24.04.2009. 16:21 ] @
Pazi, izgleda da me nisi najbolje razumeo (ili sam ja previse konfuzno pisao, sto je vrlo moguce ...) :-) Elem, naravno, nije mi ideja bila da mi neko izprojektuje bazu, vec, eventualno da pogleda/razmotri moju ideju i/ili da da neki predlog kako bi ovo moglo jednostavnije da se odradi. Zato sam i prikacio PDF sa "idejom". Znam da je dosta tesko bilo sta zakljuciti iz njega, al stvarno nisam znao za ovaj Workbench. Sad sam ga skinuo i probacu da uradim u njemu.

Btw, procitao sam odavno onu temu o Optimizaciji MySQL baze i primetices da sam u PDF-u koji sam okacio upravo koristio (ili bar pokusao) ono o cemu si pisao - normalizacija, imena kolona,... :-) Anyway, odradicu sa onim Workbenchom, pa kacim ;)

Pozz i hvala ;)
[ misk0 @ 24.04.2009. 19:09 ] @
Nisam jos pogledao PDF ali evo ideje kako bih ja rijesio te izmjene.
Ukoliko je broj tih podataka oko kojih se oni dogovaraju konacan mozes izvesti nesto ovako :
Code:

Table - Ponuda
- id
- kreator
- primaoc
- datum_kreiranja
- odobrio_kreator
- odobrio_primaoc

Tabela - Detalji_ponude
- id
- id_ponuda
- iznos
- datum_dogadjaja
- neki_deseti_podatak_oko_kojeg_diskutuju
- datum_kreiranja_izmjene


Kad neko kreira ponudu, kreira se i prvi detalj_ponude. Zatim neko od dvije strane hoce izmjeniti neke datelje - ti prethodni slog kopiras i mjenjas podatke koje on zeli. I tako nekoliko puta. Kad ispisujes njima podatke, uvijek prikazujes poslednji slog izmjene, ali u svakom slucaju u bazi imas istoriju promjena koje mozes dozvoliti da se vide ili ne. Kad se oboje usaglase oko detalja, promjene flag 'odobrio' i tad mozes, ako ti istorija ne treba, obrisati sve osim zadnjeg sloga u tabeli detalji_ponude (nesto kao usteda na prostoru).
Ovaj metod mozda nije najoptimalniji jer se cesto podaci duplaju (neko mjenja cijenu, ali ne mjenja mjesto i datum) ali ako je tih detalja malo (2-3-4) onda je OK. Ako je vishe detalja, onda mozes taj svaki detalj razdvojiti u posebne tabele ali to ti komplikuje onda operacije i kupljenje svih podataka iz querija.
[ Man-Wolf @ 25.04.2009. 15:19 ] @
@misk0 - Hvala. Nesto slicno sam i ja planirao (kao sto mozes videti [nadam se da mozes :P] iz prilozenog PDF-a) ... Odnosno, logika se isto svodi na koriscenje Flag-ova, samo sto sam ga ja, cini mi se, malo vise zakomplikovao. Nije mi uopste pala na pamet ta ideja sa cuvanjem "history"-a.

Hvala jos jednom