Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

[Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?

[es] :: Baze podataka :: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?

[ Pregleda: 4487 | Odgovora: 17 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

oJee

Član broj: 30849
Poruke: 66
*.dlp461.bih.net.ba.



Profil

icon [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?11.01.2006. u 21:24 - pre 221 meseci
Prije nekog vremena sam poceo da razmisljam o izradi baze kontakata za firmu i tad sam napravio nekoliko mogucih sema ali su mi sve izgledale nekako neodgovarajuce.

Sada su me vec i iz firme pritjerali da se toga ozbiljnije prihvatim pa bih zamolio za primjedbe i sugestije vezane za dizajn ove baze.

Od tih sema ova koju sam zakacio uz ovu poruku mi izgleda kao najpribliznije rijesenje.

Mislim da je sama sema dosta jasna do tabele "kontakti", a tu je zamisljeno da se sacuvaju podatci o funkcijama i datumima od i do kad je tu funkciju obavljala kontakt osoba. U tabeli "kontakti_podatci" bi cuvao podatke o telefonima, emailovima i nekim osjetljivijim ( i kracim) podacima kojim ne bi mogli svi pristupiti.

Najvaznije mi je pitanje dali je rijesenje tabela "drzave-gradovi-firme" najoptimalnije jer bi vjerovatno to nekad iskoristio za prosirivanje programa na finansije (kupci i dobavljaci) i/ili na evidenciju radnika (radni staz ostvaren u drugim firmama).

Hvala.



[Ovu poruku je menjao drdrksa dana 11.01.2006. u 23:07 GMT+1]
Prikačeni fajlovi
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?12.01.2006. u 10:19 - pre 221 meseci
Imas i nepotrebne redundanse:

U tabelama u kojima unosis sifru grada, nema potrebe da unosis i sifru drzave jer se ona moze saznati preko grada.

U tabelama u kojima unosis sifru firme nema potrebe da unosis sifru grada, drzave, adresu i slicno, jer to imas u podacima o firmi. Isto se odnosi i na podatke o osobi.

Ok je ovo zamisljeno, bas po skolski, ali mislim da je malo prekomplikovano za praktican rad. Previse tu ima sifarnika koji ce ti zakomplikovati unos podataka.

Probaj da malo pojednostavis. Vidi koji entiteti nisu bas toliko bitni da moraju biti uradjeni kroz sifarnik, vec ih je moguce zameniti opisnim poljem.

 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp53.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?12.01.2006. u 11:38 - pre 221 meseci
Mislim da ili ja nisam to dobro predstavio na slici ili ti nisi dobro razumio sliku. Koliko se ja razumijem u to (a ne tvrdim da se bas mnogo razumijem) redudansa nema jer je iddrzava broj od 0 do 255. U tabeli drzave je to primarni kljuc a u tabeli gradovi je to dio primarnog kljuca. Npr. ako je 1 - SCiG, 5 - Hr, 7 - BiH ... gradovi bi u tabeli bili 1-1 Beograd, 1-2 Pancevo, 5-1 Zagreb, 5-2 Osijek, 7-1 Sarajevo, 7-2 Tuzla ... isto bi dalje vazilo i za firme - iddrzava i idgrada su dio primarnog kljuca.

Uzimao sam u razmatranje i takav oblik tabele gradovi gdje oznaka drzave ne bi bila dio kljuca i tu ne bi bilo potrebe da unosim sifru drzave u tabeli firme (isto bi dalje vazilo i za tabelu kontakti gdje bi bilo dovoljno staviti idfirme) ali sam odustao zbog komplikovanosti pretrazivanja - recimo kako da odaberem sve kontakte iz jedne drzave.

Razmisljao sam i o kombinaciji ova dva nacina - da tabelu gradovi ostavim takvu kakva jeste na semi, a da u tabeli firme iddrzave i idgrada ne budu dio kljuca i u tom slucaju bi ono prethodno spomenuto pretrazivanje bilo nesto jednostavnije odraditi.

Ovo mi je dosta bitno jer kao sto sam naveo taj dio "drzave-gradovi-firme" bi iskoristio za naknadnu nadogradnju programa.

Za zakomplikovanost sa siframa se slazem ali nisam bas siguran da sam to mogao efikasno izbjeci - mada mi se cini da je sa ovakvim nacinom koji sam odabrao guzva malo podnosljivija. Podrazumjeva se da cu taj rad morati programski olaksati korisniku kroz mogucnost odabira iz combobox ili list kontrola.

Mozda ce sa ovim objasnjenjem sema izgledati malo prihvatljivije :)

U svakom slucaju veliko hvala na odgovoru.

Pozdrav.
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?12.01.2006. u 13:14 - pre 221 meseci
Gledaj ovako:

U tabeli firme imas polje idgrad. Preko tog polja u tabeli gradovi naci ces koja je to drzava (pise u polju iddrzava). Iz toga sledi da je polje iddrzava i tabeli firme nepotrebno to jest redundantno je.

Sto se tice kljuceva nad tabelama. Pravilo je da jedan kljuc ne sme da bude deo drugog kljuca. Odnosno, moze da bude (iz prakticnih vizuelnih razloga) ali to nikako ne sme da bude uslov u aplikaciji.

Drugim recima:
- tabela drzave treba da za primarni kljuc ima polje iddrzava
- tabela gradovi treba da za primarni kljuc ima polje idgrad
- tabela firme treba da za primarni kljuc ima polje idfirma

Ovi kljucevi ne smeju medjusobno biti ni na koji nacin uslovljeni, to jest potpuno su nezavisni, a veza se obezbedjuje spoljnim kljucevima tabela.

Nemoj koristiti primarene kljuceve na vise od jednog polja osim gde je to zaista neophodno.
 
Odgovor na temu

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.infonova.at.

Sajt: www.baze-podataka.net


+2 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?12.01.2006. u 13:30 - pre 221 meseci
Nekad je normalizacija viseg stepena nepotrebna i vodi ka smanjenju performansi; sve zavisi od upita.

Po pravilima normalizacije, slazem se sa brokerom i smatram da je polje iddrzava u tabelama Firme i Kontakti suvisno, ali!!! Sta ako npr. zelimo saznati sve kontakte iz jedne drzave? Onda moramo joinati vise tabela: npr. kontakti-> firme -> gradovi -> drzave.
Ovako kad je "denormalizovano", radimo samo nad jednom tabelom. Medjutim, postavlja se npr. pitanje, kako upravljati sa podacima, kada neka firma promijeni drzavu ili grad?

Ovaj dizajn je prilicno dobar i nemam konkretnih prigovora, jer ne poznajem proces unosa i ispisa podataka. Jedino sto si napravio par gramatickih gresaka, ali to nije toliko strasno. :)
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp211.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?12.01.2006. u 22:16 - pre 221 meseci
Moje izvinjenje za sve slovne i gramaticke greske i hvala vam na odgovorima ...
... ali moram priznati da sam sad zbunjen.

Po onome kako sam zamislio te tabele to bi trebalo da izgleda kao na primjeru>



Kao sto se moze vidjeti za idgrada = 1 taj grad moze biti u SCG, HR ili BIH.

Umjesto da idgrada predstavim sa integer (2*byte) i da uz taj podatak cuvam i podatak o drzavi koji moze biti i 1*byte mislio sam da napravim slozeni kljuc sa kolonama iddrzave+idgrada koji mogu biti po 1*byte. Zbog toga mislim da nema redundanse (nadam se da ne grijesim).

@broker
Mozes li da mi obrazlozis pravilo "da jedan kljuc ne sme da bude deo drugog kljuca"?
Razumijem da takav postupak povlaci povecano vrijeme indeksiranja, ali za sada ne vidim da ima druge negativne poslijedice (osim mozda prostora za te indekse).
Ti kljucevi bi trebali da se rijetko mijenjaju i da ima malo novih za unos kad se jednom krene sa radom, tako da bi brzina dobivena kod pretrazivanja bila dovoljna za zanemarivanje gubitka kod indeksiranja. Ako takav postupak ima i drugih negativnih osobina molim te da mi ih objasnis ili da mi kazes gdje bi mogao naci vise podataka o tome.

Mozda me na krivi put navodi i dosta primjera dizajna gdje navode "tabela materijala sa kljucem IDmaterijala, tabela skladista sa kljucem IDskladista i tabela smjestaj robe sa slozenim kljucem IDmaterijala+IDskladista", ili nekoliko manjih baza (access) koje sam uradio na slican nacin, a gdje nisam imao nikakvih problema.

@Dejan
"kako upravljati sa podacima, kada neka firma promijeni drzavu ili grad"

Zbog tog sto mislim da ce se to rijetko dogadjati (ako ikad) spreman sam da to odradim "rucno" tj. da programski to rijesim i na prljav nacin ako treba da bi u normalnom radu imao bolje uslove.

Dali postoji necin da se ovo izbjegne?

Dali mi savjetujete da izbjegnem "primarne kljuceve sastavljene od vise kolona" i / ili "primarne kljuceve sastavljene od vise kolona cija je jedna ili vise kolona strani kljuc"? (bez obzira sto to kompilkuje stvari na drugoj strani - pretrazivanju)

Ovo pitanje sam i postavio zato sto i poslije duzeg razmatranja nemam osjecaj da je ovo "najbolje" rijesenje, mada ne mogu izdvojiti nista konkretno kao razlog tome.

Vama jos jednom hvala na trudu.

[Ovu poruku je menjao oJee dana 12.01.2006. u 23:33 GMT+1]
Prikačeni fajlovi
 
Odgovor na temu

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.infonova.at.

Sajt: www.baze-podataka.net


+2 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?13.01.2006. u 08:23 - pre 221 meseci
Smatram da bi mozda bilo bolje da u tabeli Firme stavis samo da ti idfirma bude PRIMARY KEY, a da ti idgrad i iddrzava budu FOREIGN KEY. Tada neces imati brige o kojem gradu ili o kojoj drzavi se radi...

Osim toga, da li se moze desiti da kontakt bude npr. neka privatna osoba? Kako bi u tom slucaju popunjavao polja u tabeli Firme i Kontakti?

Kao sto sam i ranije rekao, nemam nekih vecih prigovora na dizajn baze i vjerujem da ce i ovo tvoje rjesenje zadovoljiti sve potrebe...
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp353.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?13.01.2006. u 09:12 - pre 221 meseci
@Dejan
Citat:
Osim toga, da li se moze desiti da kontakt bude npr. neka privatna osoba? Kako bi u tom slucaju popunjavao polja u tabeli Firme i Kontakti?


Moze se desiti i za taj slucaj sam mislio da polje idfirma u tabeli kontakti ostavim prazno (neobavezan podatak) a kao vrijednost u tabeli funkcija unesem privatna osoba.

Razmisljajuci o tvojim primjedbama primjecujem nekoliko stvari koje cu morati jos malo razraditi.

Cim to rijesim javit cu se sa izmjenjenom semom.

Hvala!
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?13.01.2006. u 19:03 - pre 221 meseci
Da primetim nesto u vezi PK, da li treba da bude slozen ili po jednom polju:
Citat:
Kao sto se moze vidjeti za idgrada = 1 taj grad moze biti u SCG, HR ili BIH.

Posto ti je pravilo ovakvo, ti nemas drugog izbora nego da uradiz kao sto si uradio. Sto se tice SQL standarda, OK je da se koriste slozeni kljucevi (po vise polja). Da li je to i najbolje sresenje u praksi i u svakom slucaju, moze da bude, ne mora da znaci. U tvom slucaju, ako je pravilo onako kako si ga izneo, resenje je potpuno OK.

:-)
 
Odgovor na temu

drbogi

Član broj: 5045
Poruke: 601
212.200.67.*

ICQ: 454238854


+3 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?13.01.2006. u 19:51 - pre 221 meseci
Poslušaj Brokera, ukoliko zadržiš ovakav dizajn skoro sigurno ćeš naići na probleme.

Konkretno: Tabela GRAD--: ID Drzave treba da se makne iz PK i postane FK za tabelu Državai tom logikom treba da nastaviš do kraja.


Citat:
Kao sto se moze vidjeti za idgrada = 1 taj grad moze biti u SCG, HR ili BIH.


Može biti u svakoj državi, ali u kojoj je određuješ uz pomoć primarnog ključa. Na taj način Id grada je PK za tabelu grad, i ukolio imaš npr. dva grada sa imenom "Brod", onaj u BiH i onaj u Hr bi imali različite PK tj. IDove grada.
Ako razmisliš to je logično, jer je ekvivalentno situaciji u kojoj 2 osobe imaju isto Ime i Prezime, ali se razlikuju po JMBGu, kao PK.

Citat:
Moze se desiti i za taj slucaj sam mislio da polje idfirma u tabeli kontakti ostavim prazno (neobavezan podatak)


Kada ti se ovo dogodi, pravilo je podeli tabelu, ne smeš da imaš "prazne recorde". Pokušaj da u fazi dizajna baze ne razmišljaš o konkretnom alatu u kojem ćeš napisati klijenta, usredsredi se na problem iz ugla nekoga ko nikada neće napisati ni liniju koda. Uostalom zato i postoje projektanti IS-a.





[Ovu poruku je menjao drbogi dana 13.01.2006. u 22:29 GMT+1]
 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp472.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?15.01.2006. u 21:43 - pre 221 meseci
Ovakvu semu nisam slozio “iz glave” nego sam dosta dugo razmisljao o problemima na koje mogu da naidjem. Pokusat cu da opisem kako sam razmisljao kad sam pravio tabele.

Da napomenem da tabelu kontakti koristim kao primjer za dobijanje podataka iz tabela drzave, gradovi, firme. Podatke iz tih tabela cu da koristim i u drugim tabelam (npr. tabela fakture) koje planiram naknadno uraditi na slican nacin i vrlo mi je vazno da ovo odradim kako treba.

Scenario 1>
PK u tabelama drzave, gradovi, firme su jedno polje. U tom slucaju bi sema izgledala kao na slici



@broker, @drbogi
Problem sa ovim pristupom je da je vrlo tesko-komplikovano dobiti neke podatke. Npr. ako mi treba podatak u kojoj je drzavi odredjena firma sto je jednostavniji problem, ili gori – komercijalist je rijesio da obidje kontakte u susjednoj drzavi i treba mu spisak svih kontakata u toj drzavi.
Ako postoji jednostavno rijesenje (ja ga ne znam) ovakvog problema, sa ovim pristupom bio bi prezadovoljan.

Jedo rijesenje je bilo da napravim denormalizaciju u tabelama gradovi, firme i kontakti (“malo puno” denormalizacije) ali sam bio misljenja da je tu previse posla oko odrzavanja integriteta podataka u denormalizovanim poljima.

Scenario 2>
PK postaje slozeniji sa svakom narednom tabelom

drzave – PK = (iddrzave)
gradovi – PK = (iddrzave, idgrada)
firme – PK = (iddrzave, idgrada, idfirme)
za ostale tabele PK je jedno polje.

Prednost je da je podatak o drzavi i gradu vec ukljucen i da su sva pretrazivanja po ovim vrijednostima vrlo brza (posto su to dijelovi PK i automatski se indeksiraju).
Ovim pristupom podjednostavljujem i rad sa siframa, a primjetio sam da bar ovi u mojoj firmi koji bi trebali raditi sa ovim podatcima daleko radije i brze koriste sifre ako im one imaju neki smisao. U ovom slucaju bi bilo dovoljno da sifre iddrzave, idgrada i idfirme budu maksimalno sa po tri cifre (mozda bi cak i vrijednosti od 0-255 bile dovoljne za ta polja – mada to jos trebam razmotriti) tj. identifikacija firme bi izgledala kao XXX-YYY-ZZZ (svaka slicnost sa tel brojevima je namjerna :) ) gdje je XXX sifra drzave, YYY-sifra grada u drzavi i ZZZ-firma u gradu. I na kraju u ovom slucaju nema denormalizacije.

Negativne strane su povecano vrijeme i prostor za odrzavanje ovakvih indeksa i problem kod izmjene podataka u ovakvim kljucevima. Problem izmjene podataka bi mogli podjeliti u dva dijela:
1 Dio problema koji se moze rijesiti sa opcijom “Cascade update” kod kreiranja veza izmedju tabela a sto vecina modernijih baza podrzava.
2 Dio koji se mora rijesiti zaobilaznim nacinom (npr ubacivanjem novog zapisa, prebacivanje sa starog zapisa na novi, brisanje starog zapisa)

Kao sto sam u jednom od postova prije naveo vjerovatnoca izmjene ovih podataka je vrlo mala.
Sve negativno sto sam nabrojao mi je prihvatljiv kompromis za mogucnosti koje dobivam kod pretrazivanja.

Scenario 3>
tabele drzave i gradovi su kao u scenariu 2 ali u tabeli firma PK je jedno polje.
drzave – PK = (iddrzave)
gradovi – PK = (iddrzave, idgrada)
firme – PK = (idfirme)
firme - FK = (iddrzave, idgrada)

Ovo je nekakav hibridni nacin scenaria 1 i scenaria 2 sa kojim bi bilo nesto lakse doci do podataka od scenaria 1 ali teze nego u scenariu 2, i lakse napraviti izmjenu podataka nego u scenariu 2.
Moram priznati da o ovome scenariu nisam detaljnije razmisljao.

@drbogi
Citat:
Kada ti se ovo dogodi, pravilo je podeli tabelu, ne smeš da imaš "prazne recorde"

Slazem se da tu ima greski. Za sada ne znam kako cu to rijesiti. Moram o tome porazgovarati sa ekonomistima i komercijalistima iz firme pa ce to morati sacekati ponedeljak.

Hvala vam svima na odgovorima.

[Ovu poruku je menjao oJee dana 16.01.2006. u 07:27 GMT+1]
Prikačeni fajlovi
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?16.01.2006. u 02:52 - pre 221 meseci
Citat:
oJee:
Problem sa ovim pristupom je da je vrlo tesko-komplikovano dobiti neke podatke. Npr. ako mi treba podatak u kojoj je drzavi odredjena firma sto je jednostavniji problem, ili gori – komercijalist je rijesio da obidje kontakte u susjednoj drzavi i treba mu spisak svih kontakata u toj drzavi.


Nemoj misliti da omalovazavam tvoje znanje i trud, jer mi to nije na kraj pameti, ali tu nema nikakve komplikacije. To su skolski primeri kako se radi. Upit je jednostavan, preko JOIN-a tabela i izvrsava se sigurno brzo jer je to i osnovni posao SQL servera - da nadje podatke po relacijama izmedju tabela.

Tebi se to cini komplikovano pa da bi to izbegao pravis komplikacije na drugom mestu. Sam si uvideo neke od problema koje ti tvoj model pravi i koje ti moras da resavas rucno. "Problem" u modelu kakav sam ti ja predlozio ne postoji, jer se radi samo o tome da u upit dodas jedan LEFT join po dodatnom sifarniku kako bi mogao da filtriras podatke i po tom uslovu. Ceo posao ti odradi SQL server i to bas onako kako je i predvidjeno da on resava probleme.

Od starijih kolega sam naucio jedan vazan stav kada su u pitanju SQL baze: ako mozes da napravis SQL upit koji ce da obavi neki posao, ma kako komplikovan bio, koristi taj upit, a nemoj pokusavati da problem resavas zaobilazno, sopstvenim kodom. SQL server je projektovan i optimizovan da bolje resava svaki zadatak u baratanju sa bazom koji se moze opisati SQL-om, nego sto mozes ti, dodatnim programiranjem.

Optimizacija rada sa bazom se radi tako sto optimizujes SQL upit a ne tako sto zaobilazis SQL i pravis sopstvena programska resenja. Izuzeci, naravno, uvek mogu da se nadju, ali ovo tvoje nije takav slucaj.

Sto se tice sifarnika gradova (povodom nastojanja da ukucavanje sifara bude pojednostavljeno korisnicima programa), uopste nije problem da im obezbedis sifre koje imaju smisao. Ja bih cak predlozio da za sifre zemalja koristis standardne dvoslovne oznake, a za sifre gradova koristis kombinaciju: dvoslovna oznaka zemlje + pozivni broj mesta (mada ti to nije jednoznacno jer cesto vise mesta ima isti pozivni broj). Dakle, tvoj korisnik ce da ukuca na primer yu011 za Beograd ali ce to biti jedna sifra upisana u jedno polje idgrad, ali ono "yu" nece imati nikakvu funkciju oznake drzave vec samo nacin da obezbedis lakse pamcenje sifara korisnicima. Sifra zemlje se sa gradom povezuje posebnim poljem idzemlja, u tabeli gradovi koje sluzi za lookup prema sifarniku zemalja, a ne kao deo primarnog kljuca tabele gradovi.
 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp453.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?17.01.2006. u 08:19 - pre 221 meseci

@broker
Citat:
Nemoj misliti da omalovazavam tvoje znanje i trud, jer mi to nije na kraj pameti, ali tu nema nikakve komplikacije.


Na takvo sta nisam ni pomislio.
Ni ja ne zelim da omalovazavam neciji trud i znanje. Nekakvo znanje o bazama imam, ali ono nije preveliko i uglavnom je vezano za Access. A da mislim da sve znam i da se bojim kritike ne bi postavio temu sa nazivom "primjedbe i sugestije?" nego bih stavio "najbolje rijesenje i tesko onom ko ga se ne pridrzava" po sistemu - moj glas je tvrd ali je toljaga jos tvrdja .
Cilj mi je da date tabele uradim kako treba i da kroz nekakav razgovor nesto i naucim. Zato obicno i trazim nekakvo objasnjenje "zasto i kako" jer mi je bitnije da vidim na kojim mjestima ispravno razmisljam, a na kojima pravim greske i zbog cega pravim greske. Zao mi je, ali sam takav, nije mi dovoljno "ovo je dobro, a ovo nevalja" nego tezim da znam zbog cega je nesto ispravno, a zbog cega nije ispravno - ako nista drugo tako imam bolje temelje za raspravu .

Citat:
Tebi se to cini komplikovano pa da bi to izbegao pravis komplikacije na drugom mestu.


Pa valjda mi je draze da se borim sa poznatim komplikacijam, nego sa nepoznatim

Posto sam vec spomenuo da se zasad jos uvjek najbolje snalazim sa Accessom pokusacu da pojasnim primjerom. Pretraga za kontaktima u jednoj drzavi bi izgledala:
po scenariu 1:
Citat:
SELECT kontakti.idkontakt, drzave.iddrzava
FROM (drzave INNER JOIN gradovi ON drzave.iddrzava = gradovi.iddrzava) INNER JOIN (firme INNER JOIN kontakti ON firme.idfirma = kontakti.idfirma) ON gradovi.idgrad = firme.idgrad
WHERE (((drzave.iddrzava)=5));


po scenariu 2:
Citat:
SELECT idkontakt, iddrzava
FROM kontakti
WHERE (((kontakti.iddrzava)=5));


Moje komentar o komplikovanosti se uglavnom ne odnosi na velicinu SQL "kobasice". Posto nisam imao puno dodira sa serverskim bazama mene ovdje interesuje dali ima razlike u vremenu izvrsavanja ovakvih upita i ako ima kolika je ta razlika?
Pristup toj bazi namjeravam uraditi preko web servera i u pocetku bi na njoj radilo do 5 korisnika, a kad zavrsim program sa svim modulima oko 20-ak korisnika. Pretpostavljam da je ocekivati da ce se broj korisnika popeti na maksimalno 50 ako rijesim ostaviti pristup se interneta ka nekim "modulima". Za sada planiram da bude 6 "modula" a za 5 ce ove tabele (drzave, gradovi, firme) da budu bitne.
Dali je ovo vrijeme znacajno?

Citat:
Ja bih cak predlozio da za sifre zemalja koristis standardne dvoslovne oznake

Tvoj prijedlog mi se svidja, ali me opet interesuje brzina rada sa tekstualnim siframa u odnosu na brzinu rada sa brojnim siframa.

Dakle, moja glavna nedoumica je dali je brzina rada server baza + web dovoljna za 50 -ak istovremenih korisnika koji ce raditi i sa ostalim tabelama (kojih ce biti oko stotinu) da nemoram brinuti o brzini izvrsavanja pojedinih operacija?

Hvala na trudu i nemojte da puno zamjerite mojoj tvrdoj glavi
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?17.01.2006. u 08:45 - pre 221 meseci
Citat:
oJee:
Posto nisam imao puno dodira sa serverskim bazama mene ovdje interesuje dali ima razlike u vremenu izvrsavanja ovakvih upita i ako ima kolika je ta razlika?


Razliku u brzini dobijanja rezultata mozes slobodno da zanemaris.

Citat:

Tvoj prijedlog mi se svidja, ali me opet interesuje brzina rada sa tekstualnim siframa u odnosu na brzinu rada sa brojnim siframa.


Mozes slobodno da zanemaris razliku. No ako ti je bas stalo da budu brojevi uvedi brojcane sifre za drzave pa opet radi isto kao i sto bi sa slovnim.

Citat:

Dakle, moja glavna nedoumica je dali je brzina rada server baza + web dovoljna za 50 -ak istovremenih korisnika koji ce raditi i sa ostalim tabelama (kojih ce biti oko stotinu) da nemoram brinuti o brzini izvrsavanja pojedinih operacija?


Nije bas jasno da li nameravas da bazu radis u Access-u ili na nekoj drugoj platformi. Ako planiras da krsitis Access, onda ti je to veci znak pitanja za planiranu namenu. Za tako nesto treba pravi SQL server.

Sto se tice opterecenaj i ovih upit, oni su tako jednostavni, da, kada bi bilo pitanje da li su oni problem, sta bi tek bilo sa mnogo komplikovanijim poslovima. Ne brini, radice sve to kako valja. Ak ce korisnici prisupati bazi preko web interfejsa tek tad ne moras da se brines za bazu, jer web interfejs je spor i samim tim ce rasterecivati bazu, jer nece moci da je zatrpa sa upitima.
 
Odgovor na temu

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.infonova.at.

Sajt: www.baze-podataka.net


+2 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?17.01.2006. u 09:12 - pre 221 meseci
@oJee: Ne trpaj u aplikaciju ono sto mozes obaviti SQL-om. Tvoja aplikacija sigurno nije 'time-critical', pa da moras toliko brinuti o vremenu izvrsavanja nekog upita.

Sto se tice SQL kobasica, ni to ne treba da te plasi. Mi ovdje radimo svakodnevno 'kobasice' od pola ili cijele stranice A4 formata i sve radi savrseno. Ako su relacije medju tabelama dobre, ako imas postavljene indexe i ako si SQL upite dobro slozio - nema razloga za tolikom paranojom da "nesto ne valja".

Evo da pogledamo tvoje scenarije...

1.
Code:

SELECT kontakti.*
FROM drzave, gradovi, firme, kontakti
WHERE drzave.iddrzave = 5
    AND gradovi.iddrzave = drzave.iddrzave
    AND firme.idgrada = gradovi.idgrada
    AND kontakti.idfirme = firme.idfirme
Vidis da nije problem? :)

2.
a) Pretpostavimo da neka firma promijeni svoju lokaciju i poslovanje preseli u drugi grad u drugoj drzavi (npr. iz HR u SiCG ili obrnuto). U tom slucaju ces uz denormalizovanu tabelu morati mijenjati samo kljuc (idgrada, iddrzave, idfirme).

Ako je tabela normalizovana, onda samo mijenjas FK idgrada u tabeli firme.

Sta je lakse zamijeniti - kljuc sa jednim poljem ili kljuc sa vise polja?

b) Ako se zbog nekih politickih peripetija jedan grad pripoji drugoj drzavi (rijedak slucaj, ali da teoretski pokrijemo sve moguce slucajeve), onda ces morati mijenjati slijedece podatke:
Denormalizovana tabela:
- gradovi: (iddrzave, idgrada)
- firme: (iddrzave, idgrada, idfirme)

Normalizovana:
- gradovi: iddrzave
- firme: idgrada

pri cemu ti idfirme ostaje nepromijenjen.

3. Pretpostavka kao i 2. scenariju.
Denormalizovana tabela:
- gradovi: (iddrzave, idgrada)
- firme: FK (iddrzave, idgrada), PK idfirme ostaje isti.

Normalizovana:
- gradovi: iddrzave
- firme: idgrada

I opet pitanje - sta je lakse odrzavati? Kljuc sa jednim poljem ili kljuc sa vise polja?


Nadam se da vidis razliku...

Osim toga, postavlja se jos pitanja...

Sta ako neka firma ima vise filijala/biroa/kancelarija u jednom gradu?
Sta ako neka firma ima filijale u vise gradova u jednoj drzavi?
Sta ako neka firma ima filijale u vise drzava; u vise gradova u vise drzava...?

Da li si razjasnio situaciju, kada je kontakt privatna osoba, a ne firma?

Da li si siguran da si pokrio i ove slucajeve?

[Ovu poruku je menjao Dejan Topalovic dana 17.01.2006. u 10:15 GMT+1]
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp274.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?17.01.2006. u 09:16 - pre 221 meseci
Ma kakav Access za serversku bazu, nisam valjda prolupao . Znam da je moguce, ali mislim da je vrijeme da krenem dalje

Ovo sam planirao raditi kao kombinaciju postgre + tomcat mada mi sad na prvi pogled ni Oracle XE ne izgleda lose.

Znam da su ovi upiti jednostavni, ali se odnose na dati dio planirane baze koji sam i naveo u temi poruke (koja mi sluzi kao primjer na kome zelim da razjasnim svoje nedoumice).
Ocekujem mnogo komplikovanije upite i zato mi je pitanje o brzini bitno jer ako vec imam razliku na ovakvim upitima kakva ce stvar biti kad budem poceo povezivati sve planirane module? Jos ako uzmem u obzir da bi 2 planirana modula mogla povremeno biti i racunski zahtjevna.

U redu sto je web interfej spor, ali za onih 20ak korisnika koji ce pristupati sa LANa ne bi trebalo da bude presporo

Pozdrav!
 
Odgovor na temu

oJee

Član broj: 30849
Poruke: 66
*.dlp274.bih.net.ba.



Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?17.01.2006. u 09:38 - pre 221 meseci
@Dejan
U pravu si, aplikacija nije 'time-critical' mada ce na trenutke biti racunski zahtjevna, ali to nije tolko bitno da bi morao o tome razbijati glavu.

Mislim da jesam razjasnio situaciju privatna osoba - firma. Prihvatam da trebam staviti PK od jednog polja i odraditi povezivanje na predlozeni nacin, trebam jos razmisliti o koriscenju tekstualnih sifri. Cim sve to "svarim" priakcicu novu semu.

Hvala svima na strpljenju! :)
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?17.01.2006. u 10:08 - pre 221 meseci
Performanse sa tekstualnim šiframa (CHAR(2)) ne bi trebalo da se uopšte razlikuju od performansi sa dvobajtnim integerom.
 
Odgovor na temu

[es] :: Baze podataka :: [Dizajn] Baza poslovnih kontakata - primjedbe i sugestije?

[ Pregleda: 4487 | Odgovora: 17 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.