to nije neki problem ali MORAS da smislis PRAVILO na osnovu kojeg ce se kljucevi
uskladjivati...

jer aplikacija mora da zna na kako da ih uskladi, a ti ovde nisi naveo detalje o tom procesu...

recimo jedno od resenja bi moglo da bude da postoji neko polje (recimo nek se zove NAZIV_MODELA) koje ce biti zajednicko podacima na klijent i na server strani, pa kad se klijent apdejtuje sa serverom, uporedjuje ovo polje i na lokalnoj strani uskladi id_modela da bude isti kao na serveru ako je NAZIV_MODELA ISTI) naravno onda na klijentu to izmeni i u RADNIM_NALOZIMA...

ne znam da li sam bio jasan i da li to uopste moze da se upotrebi ali iz moje perspektive to je najcise sto mogu da ti pomognem

probaj da malo vise detalja das naci ce se vec neko resenje...

poz
Uncle Blob

Sta ti znaci klijent server sa modelom koji nije povezan non-stop?
Objasni nam sta u stvari tvoja baza treba da radi. Opisi nam poslovni proces koji baza treba da podrzi. Na primer ovako: "Mi smo radionica/atelje/firma za izradu Modela. Svi modeli koji se izrade, treba da se dodele nekom radnom nalogu. Mi modele prvo napravimo, pa ih onda dodelim radnom nalogu. Hocemo bazu koja prati taj proces." Onad mozda nesto mozemo da pomognemo.

:-)

Hvala na dosadasnjim odgovorima,

pa da pokusam da budem jasniji. Da malko pojasnim klijent - server arhitektura nije
bas najsrecnija definicija potrebne arhitekture vise bi to bilo distribuiran sistem
ili kvazi-distribuiran sistem ( mada je i ovo nezgrapna definicja i ne odgovara
opisu problema ).

Kao sto je prethodnik napisao ajde da ja to razlozim na poslovni proces pa ce mozda
da bude jasnije svima.

Problem je sledece vrste. Potrebno je napraviti bazu podataka za Servis Mobilnih
Telefona. Da napomenem da je prethodna verzija ( v1.0 ) vec odradjena i da
funkcionise. Kako su apetiti klijenta porasli ukazala se potreba za prosirenjem
postojeceg informacionog sistema novim tabelama i podacima. Klijent takodje ima
zahteve i za boljim grafickim okruzenjem pa je zbog toga sem obicnih tekstualnih
podataka u bazu potrebno implementirati i slike ( slike modela mobilnih telefona ).

Kada program bude zavrsen ( recimo da je rok Januar 2006. ) klijent dobija bazu
koja je up to date sa danasnjim stanjem na trzistu sto se tice modela mobilnih
telefona. Da bi i dalje bio " up to date " ja sam zamislio da zakupim neki domen
i da klijentima ( ne samo ovom klijentu, jer je vec vise njih iskazalo interes za
ovakvom aplikacijom - videli su screen shotove ) omogucim da putem interneta preuzmu
nove modele mobilnih telefona - putem nekog script fajla koji ce update-ovati bazu.

E sad, problem nastaje sta ako se u servisu zatekne neki model koji nije u tabeli modeli ?

Moram da omogucim korisniku da ga unese, i zatim da izda servisni_nalog na taj telefon.

Nakon toga ( recimo proslo je 1 mesec ) ja taj isti model ( odnosno podatke za taj model sa
pripadajucim slikama ) postavim na internet i onda korisnik prezume fajl, update-uje bazu
i sad treba da se i radni_nalozi update-uju tako da ID_MODELA ne bude vise onaj ID koji je
korisnik uneo vec da bude ID_MODELA onog koji se nalazi u script fajlu.

Jos jedna napomena, ovakav scenario nije cest recimo da je 2 - 3 % slucajeva bas ovakav scenario,
ja ne stignem da izbacim novi update a telefon je vec stigao u servis.

Scenario se umnogome pogorsava kada klijent nije redovna musterija, vec propusti nekoliko
update-ova ( recimo nece da placa mesecno odrzavanje ) vec se posle 6 meseci do godinu dana
odluci na update. A u medjuvremenu je nagomilao preko 3000 naloga na tabeli MODELI koju nije
update-ovao.

Sto se tice prvog scenarija mozda on i nije tako strasan ( mogao bih da oznacim te radne naloge
kao problematicne i da ih update-ujem nakon update-a tabele MODELI ). To bi mi oduzelo malo
vremena i ponesto truda.

Sto se tice drugog scenarija, zaista mi nepada na pamet da trosim sate i sate u prepravljanju
tabele RADNI_NALOZI.

Mora da postoji neki laksi nacin da se preduprede ovakve situacije, zato sam se obratio Vama
na forumu da cujem neka pametnija resenja od ovih koje sam ja sam smislio.

Pozdrav i hvala,
Aleksandar

Mozda ja nisam shvatio ali ....

Tebi su modeli_telefona zapravo sifarnik?
Znaci ti ukoliko korisnik nema vrijednost u sifarniku (novi telefon) mu dozvoljavas da ga unese. Logicno.
I sad, korisnik radi update i ti zelis da ukoliko skine update kreira novu stavku u sifarniku (moguce duplu) sa ispravnim karakteristikama telefona? Oki, ali zasto moras update-ovati radne naloge?
Zar nije jednostavnije da prilikom update-a potrazis da li vec postoji taj model (na osnovu nekog polja, opisa, naziva ili sta vec, biti pazljiv na razmake i slicno) i ako postoji, samo updatujes njegove karakteristike.
Tako ne bi morao da prepravljas radne naloge jer sifra prema modelu ostaje ista, a ti si update-ovao podatke o telefonu.

Nakon toga negdje zapises datum zadnjeg update-a i to je to. Sve fajlove koje skidas sa servera nazoves po datumima ili slicno i uvijek skidas fajlove 'poslije zadnjeg update-a'.

Mozda nisam dobro shvatio tvoj problem?..

Da, ovo poslednje je bas to,

ali problem kako naterati korisnika da napise bas NOKIA 7210i recimo, da bih ja mogao da pretrazim tabelu_modela bas po nazivu ?
Sta ako unese nokia 7210i a da ne govorim o nekim egzoticnim telefoima tipa ALCATEL DB@ i slicno ?

To pretrazivanje tabele modela telefona mi je vec donekle palo na pamet i pomislio sam na to ali posle par razmisljanja i mogucih scenarija samih korisnika to nece da bude bas dobro resenje.

Cak i danas u ovoj verziji programa ( v1.0 ) on ima duple kljuceve modela a ima samo dva polja MODELI(id_modela int, naziv_modela varchar(50)).

Evo primera korisnik je uneo: (123, 'SAMSUNG CFX65') a nedugo zatm
(165, 'samsung cfx65'). To je samo jedan primer.

Nesto sam mislio da to mozda realizujem kao sto su realizovali programeri koji su razvili FOOTBALL MANAGER 2005 - 2006 Sports Interactive firme.

Oni su dozvolili korisniku da sam ubacuje slike fudbalera a povezivanje sa realnim podacima u bazi su odradili putem XML koji se ucitava odmah nakon ucitavanja baze i vrsi se spoljne povezivanje. Samo sto bih ja to uradio sem za slike vec i za ostale podatke za model telefona.

Uz program bi bila isporucena mala aplikacijica koja bi mu sa leve strane izlistala postojece telefone u tabeli modeli. A zatim sa desne strane pune podatke za gomilu novih telefona, ako vec postoje na desnoj strani potrebno da je da ih upari, ako ne onda je posao lak jer samo ubacujem nema nikakvog update.

Mozda je ovo i najelegantnije resenje, ako ne vi me opovrgnite i dajte jos ideja.

Hvala vam na vremenu.

Pozdrav Aleksandar

Tipican metod "odbrane" od ovakvih situacija, tj prepoznavanje duplikata je pretvaranje teksta u npr velika slova, uklanjanje belina i crtica, a zatim poredjenje.

Dakle

NOKIA 7210i postaje NOKIA7210I
nokia7210i postaje NOKIA7210I
ALCATEL DB@ postaje ALCATELDB@
itd...

Mozes upotrebiti i artiljeriju regularnih izraza, ali gornji pristup je dovoljno dobar.

Dodatno, korisniku mozes ostaviti mogucnost da rucno izabere telefon u bazi (ukoliko ne mozes da ga prepoznas po upisanom imenu), tj omogucis i pomoc coveka pri sinhronizaciji.

To je ok nacin, ali bi mogao jos i ...
Pri unosu novog telefona, kad otkuca naziv da provjeris da nema u bazi 'neki slican naziv' i ako ima kazes mu 'Znas, vidi, gledaj, ima to vec upisano. Jesi ti siguran da zelis jos jedan isti?'. Tako bi sprijecio duple unose.
On ce sa tim duplim unosima jedan dan praviti fakture sa jedno sifrom, drugi dan sa drugom, tako da ti nikad osim rucno neces moci to da ispravis.

Ljudi sve ja vas razumem,
ali da li ste vi nekada radili program za korisnike ?

Ja predvidim 100 mogucih situacija, a on uradi 101. nemogucu i nedozvoljenu !!!

Pa nisam ja Hudini da mu sad proveravam sta je uneo, pa da to transformisem u ne znam ni ja sta. Ima i on da poludi a i ja predvidjajuci moguce scenarija.

Mislio sam da ima neko lepse, da tako kazem elegantnije resenje, ovo su brutal force resenja. Nateraj ga da unese ono sta ja hocu i kako ja hocu.

Zato je i pitanje bilo sinhornizacija baza.

OK, izvini što sam pokušao da ti pomognem, neće mi se ponoviti.

_{[Ovu poruku je menjao obucina dana 12.12.2005. u 19:13 GMT+1]}

Druze, veruj mi vec godinu i pol se borim sa korisinicima i znam o cemu pricam:

nisam imao iste probleme kao ovaj tvoj ali slicne...

moras naci sredinu... neke stvari moras dopustiti korisnicima da biraju i prilagoditi
program situaciji a negde moras malo i da 'ogranicis' korisnike da nebi sebi zagorcao
(programerski) zivot...

po meni resenje tvog problema je vec ovde pomenuto:

ako se korisnik posle duzeg vremena (i unosenja modela telefona) odluci na update
sa tvojom bazom modela, uporedi nazive modela... (recimo uzmes UPPERCASE nazive iz njegove baze i iz tvoje i uporedjujes).

tamo gde je moguce upariti, tamo lepo zamenis podatke (sifre), tj promenis njegove sifre modela u tvoje i isto odradis i sa radnim nalozima...

a tamo gde je nemoguce upariti nazive, tamo nema drugog nacina nego da pitas korisnika (ne moze da nastavi sa radom dok ti ne odgovori na sva pitanja), recimo da za svaki model za koji ti ne mozes da nadjes par, on ima sledece opcije:

1. upari sa odredjenim modelom u tabeli na MAIN serveru (ponudis mu listu)
2. ostavi na cekanju (i onda ga za ove modele pitas pri svakom startu, a do tada ih ne obradjujes ili tako nesto)

e sad znam da mozda ovo nije najsretnije resenje ali ovaj pristup mi jedini pada na pamet...

ajd bas javi sta si uradio da svi nesto naucimo...


poz

@staleks: Nacin sinhronizacije koji ti vrsis je po meni neprihvatljiv kao rjesenje uskladjivanja podataka na odvojenim bazama.
Moras imati neki bolji i sigurniji mehanizam sinhronizacije/replikacije, kako bi osigurao konzistentnost podataka (npr. primary i foreign kljuceva).

Ne dopusti takav nacin unosa podataka. Zasto ne uradis jednu web aplikaciju, kojoj ce korisnici pristupati preko browsera ili eventualno neke desktop aplikacije, koja se spaja na server aplikaciju, a uz to da podatke drzis centralno u jednoj bazi na serveru.

Tako moze vise korisnika istovremeno da pristupa podacima, bez straha od gubljenja ili prepisivanja (override) podataka...

Sto se tice ogranicavanja unosa podataka, NAJSIGURNIJE je da im ti ponudis predefinisane opcije/vrijednosti za unos, pa nek oni biraju sebi sta im odgovara...


_{[Ovu poruku je menjao StRiPy dana 13.12.2005. u 09:25 GMT+1]}

Stripy,

apsolutno si ti upravu, u idealnom slucaju, ali ako procitas njegove 'informacione zahteve' mozda ces shvatiti zasto sam ponudio resenje koje sam ponudio...

jasno mi je da resenje ne ispunjava 'trecu normalnu formu' ali ovo je real-life problem...

korisnik ne apdejtuje bazu mesecima i onda se pojavi i ocekuje da se sve samo odradi...

znam i ja kako ne treba ali sam pokusao da ponudim resenje koje bi 'radilo posao'...

zasuci rukave pa ponudi resenje kje radi a pritom ne rusi temelje relacionih baza podataka, i ja ti skidam kapu...

pravilo:

ako kritikujes, onda ponudi bolje resenje, u suprotnom, mlatis praznu slamu sto bi rekao nas narod...

nemoj sad da se uvredis nego ajde da probamo naci resenje koje radi...

poz.

_blob_: sorry, nisam se obracao tebi, nego staleksu. :)

nema problema, nisam se ja uvredio, ali mi se ucinilo da je post upucen meni...
( :paranoja: )

u svakom slucaju, njegov problem postoji samo zato sto aplikacija nije zamisljena
kako treba u pocetku, jer da je to odradjeno kako treba u startu, ovaj problem se ne bi
ni javio...

Dizajn, dizajn i dizajn...

obicno se to desava kada neka aplikacija pocne da radi nesto za sta nije dizajnirana kada je pravljena... to je klasika u praksi

bas me interesuje kako ce se ovo resiti...


Pozdrav Stripy!

staleks,
to što ti hoćeš da uradiš (ako sam dobro shvatio problem)
da si 100% siguran da kontrolišeš unos je prosto nemoguće.
Razlog je vrlo jednostavan: kako možeš da znaš kakav će
novi naziv izmisliti u budućnosti i u kakvom će obliku biti,
znači moraš dozvoliti korisniku bilo kakav unos, a ne da ga kontrolišeš.
E sad, kao što drugi rekoše, djelimično rješenje, a možda i
sasvim zadovoljavajuće je upoređivanje po sličnosti.

Tabelu modela proširi i dodaj polja PROIZVOĐAČ i M_NAZIV (u kojima će biti
odvojeni nazivi proizvođača i naziv modela bez imena proizvođača).

Unos u polje PROIZVOĐAČ možeš dobro da kontrolišeš izborom
iz pomoćne tabele već poznatih "svih" proizvođača, koja se mijenja rijetko
npr. uvijek će povući NOKIA, a ne nokia, Nokia, NOKIjA, nokiia...
i biće uvijek ispred NAZIVA modela. U pomoćnu tabelu poznatih
proizvođača dozvoliš samo dodavanje novih proizvođača i to u neko
posebno polje u koje korisnik može unijeti bilo šta (pa i
nokiia - možda tako stvarno i bude naziv novog proizvođača?).
Eto, problem je već i kod naziva proizvođača - kako kontrolisati?
Ovo polje će biti samo kao podsjetnik korisniku kod budućeg uparivanja
i nećeš u njemu provjeravati unos, a i ti ćeš u međuvremenu svoju
relevantnu bazu dopuniti i distribuirati.

Druga stvar, M_NAZIV kojeg ti popunjavaš u svojoj tabeli
pri upoređivanju rastaviš na sastavne dijelove, npr. ako je
naziv SGH-X427M onda imaš SGH, X, 427, M
(rastavljaš na riječi odvojene razmakom, crticom ili drugim specijalnim
znakovima, a onda i na poddijelove - samo grupa slova, samo broj...)
i pretražuješ M_NAZIVE koje je korisnik unosio, pa ako pronađeš onaj u
kome su sadržane sve riječi (ili većina) - onda je to to.
Primjer: sghx427m, sgh x427m, SGHx 427 m, x427m SGH... odgovara,
a s9h-x427m, 5gh427m, sgh427... ne odgovara tj. to su moguće
drugi modeli. U ovakvim slučajevima ponudiš korisniku da on sam
pridruži modele, a M_NAZIV koji već odgovara odmah čekiraš.

Uostalom, tako i web pretraživači u suštini rade, ukucavaj na razne
načine naziv nekog modela u google pa pogledaj rezultate, a kad
pogledaš keš neke pronađene stranice tamo ti svaki sastavni dio
traženog pojma oboji drugačije i označi u tekstu.
Napomena za korisnike da obavezno unose M_NAZIV tačno onako kako
je označeno na telefonu može dosta pomoći, to povećava vjerovatnoću uparivanja.
Ovo je sve nagrubo, ima tu štošta da se dotjera
I još jedna veoma važna stvar, ako korisnik neće da se drži tih nekih osnovnih
pravila onda ga lagano lupiš po džepu, pa svi zadovoljni

@ obucina: Izvini ako je post zvucao odbojno, nije mi to bila namera, vec jednostavno znam da i obicno kliktanje misem na dugme za neuke korisnike zna da bude problem, a zamislite tek ovo da ga teram da postuje unapred dogovoreni format unosa naziva modela telefona. Kanda nece moci :)



A ko je u pocetku i rekao da ja hocu da ga ogranicavam pri unosu ? Ja sam samo rekao da mi treba update na osnovu neke tabele koju cu ja generisati posle nekog vremena na serveru sa svim podacimo i slikama odgovarajuceg telefona. Svestan sam ja ovog ogranicenja kako cu znati kakav ce naziv nokia dati svom sledecem telefonu ?
Pa evo vam primera, nokia obicno ima 4 broja prva brojka predstavlja seriju itd, na kraju poneki put moze da ide oznaka "i" ali i ne mora. I sad ako ja predvidim tu situaciju a oni izbace NGAGE ? Pa zatim i NGAGE QD. I tako redom, problem za problemom.

Zato sam ja i mislio da mora postojati neko resenje sa ovakvom vrstom problema. To tako lepo mirise na distribuiranu obradu podataka ...



@_BloB_: E sad mi ovo vec ne zvuci kao dobronamerna kritika. A mozda i jeste.
Ja nisam programer od juce, Informacione Sisteme sam zavrsio, ali kao sto si rekao
ovo je problem iz prakse. Kako ja da korisniku obezbedim non-stop konekciju na server ?
koliko to zaista firmi u Novom Sadu ima ? Verujte mi da znam da cak ni mnogo jake firme ( drzavne ) nemaju non-stop konekciju ka serverima u Bgd-u a kamoli ja da malog privatnika teram da to obezbedi.

Sto se tice trece normalne forme, da bih ti dokazao da znam o cemu pricam, ovde cini mi se ulogu ne igra TRANZITIVNA ZAVISNOST koja je kljucno obelezje 3NF vec je ipak problem fizickog ogranicenja. TRANZITIVNA ZAVISNOST bi u ovom slucaju znacilo da neki od podataka u tabeli RADNI_NALOZI zavisi od svog primarnog kljuca id_radnog_naloga a pri tome i od spoljnjeg kljuca id_modela . Kako nema takvih podataka u tabeli RADNI_NALOZI, sto se tice modela, u tabeli RADNI_NALOZI se nalazi samo kljuc tabele MODELI ( id_modela ) to ovde nije slucaj sa 3. normalnom formom.

A mozda i ja gresim ? Izvinjavam se u svakom slucaju.

Sto se tice resenja, ima da ga nadjem vec nekako, samo sam hteo da cujem da li imate ideje, kao sto vidim imate. Neke dobre, neke manje dobre ali u svakom slucaju hvala vam svima na trudu i ulozenom vremenu.
Nek ostane ovo otvoreno pa nek jos ljudi ucestvuje u raspravi.
Nisam ja sad posisao svu pamet sveta pa sam ja taj koji ce da odluci sta je najbolje.

Zasto mi se ovo resenje o poredjenju ne svidja ? Pa iz 2 razloga, prvi sam naveo kako cu isproveravati neke nove nazive telefona , drugi je da ce mi samo programiranje provera oduzeti mnogo vise vremena. Vreme * programerski sat = cena programa ce da enormno skoci sto svakako korisniku ne pada na pamet da plati.

Posto kažu da jedna slika govori više od hiljadu reči evo i deo dizajna šeme relacije:



_{[Ovu poruku je menjao staleks dana 14.12.2005. u 17:35 GMT+1]}