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

Teorija Vs. Praksa

[es] :: Baze podataka :: Teorija Vs. Praksa

Strane: 1 2 3 4

[ Pregleda: 20386 | Odgovora: 73 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Radudzoni
Radoslav Jovanovic
Beograd

Član broj: 8384
Poruke: 133
*.ptt.yu.



Profil

icon Teorija Vs. Praksa16.07.2006. u 10:52 - pre 185 meseci
Hteo bih da cujem vase misljenje o nekoliko razlicitosti izmedju teorije i prakse a u vezi projektovanja baze podataka, a prva je:

- Imamo dva objekta u bazi, recimo Radnik(RadnikID, Ime, DatumZaposlenja...) i Zadatak(ZadatakID, Opis, ...) , kardinalnost sa obe strane je 0..m (vise prema vise).

U teoriji se, kod prevodjenja u relacioni model, u ovom slucaju formiraju tri relacije

1. Radnik(RadnikID, Ime, DatumZaposlenja...)
2. Zadatak(ZadatakID, Opis, ...)
3. Radnik_Zadatak(RadnikID, ZadatakID)

medjutim, u praksi se uglavnom srece razlicitost kod trece relacije pa ona postaje

3. Radnik_Zadatak(Radnik_ZadatakID, RadnikID, ZadatakID)

ZASTO????

U bivsoj firmi sam dobio odgovor da je to bila preporuka u cilju poboljsanja performansi kod Access baza.
Interesuje me da li je to jedini razlog...?

Gledajuci demo baze koje dolaze uz SQL Server, zakljucio sam da je svaka od tih baza je izmodelovana na prvi nacin.

Kakvo je vase misljenje u vezi ovoga???
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa16.07.2006. u 16:21 - pre 185 meseci
Ume da bude prakticnije baratati podacima kada je primarni kljuc jedno polje a u "skolskom" primeru to jest prvoj varijanti, kljuc su dva polja.

E sad, kako ce u konkretnom slucaju da se radi, zavisi od toga kako ce se ti podaci dalje koristiti. Ovo se uglavnom primenjuje ako recimo postoji neka cetvrta tabela koja se referencija na tu trecu, ali se radi rucni unos, pa da ne bi operatori morali da unose i radnika i zadatak, onda se uvodi dodatno polje koje postaje kluc tabele tako da operator popunjava samo jedno polje koje referencira na tu tabelu.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.tippnet.co.yu.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Teorija Vs. Praksa16.07.2006. u 20:52 - pre 185 meseci
Po meni je odgovor zavisi od sistema koji se modelira.


-----
1. SLUCAJ:
Predpostavljeni pise odluku o rasporedjivanju radnika na zadatak i ta se odluka zavodi u delovodnik (te ima delovodni broj - analogija sa tvojim primerom je Radnik_ZadatakID). Ovaj upis u delovodnik ima i datum koji trenutno nije bitan.

U ovom slucaju odluka o rasporedjivanju iz stvarnog sveta i njen atribut Radnik_ZadatakID postaju bitan deo sistema. Na broj te odluke se pozivas kada radniku izrices disciplinske mere, kada masina radniku otkine ruku, ...

Dakle u ovom slucaju ja bih se odlucio za drugu verziju iz tvog primera.


-----
2. SLUCAJ:
Rasporedjivanje radnika nije bitno za sistem. Nije bitno ko ga je i kada rasporedio. Bitno nam je samo da on radi.

Neka seka uvodi raspored radnih zadataka u kadrovsku evidenciju. Nju je bas briga da li je Radnik_ZadatakID = 7, 80 ili 32767. Dakle Radnik_ZadatakID je nebitan za odvijanje poslovanja u stvarnom svetu. Ako je nebitan onda je nepotreban.

Dakle u ovom slucaju ja bih se odlucio za prvu verziju iz tvog primera. Netreba bezati od kompozitnih kljuceva.


-----
Na kraju moram da prokomentarisem ono o 'u cilju poboljsanja performansi'.

Svo JOIN-ovanje tabele Radnik_Zadatak sa tabelama Radnik i Zadatak se radi bez upotrebe tog novog atributa Radnik_ZadatakID. Ubacivanje atributa Radnik_ZadatakID povecava kolicinu podataka u tabeli Radnik_Zadatak za 50%! Ni meni nije jasno kako to moze povoljno da utice na performanse.

To je kao sto ja imam neke visoke case za vodu i koje nepaznjom cesto prevrcem. Resenje mog problema nije da pazim kako ih upotrebljavam, vec da ih do trecine napunim kamenjem da bi se teze prevrtale :)


"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa16.07.2006. u 21:21 - pre 185 meseci
U tome se, u mom slučaju, teorija razlikuje od prakse.

Naime, pri projektovanju baze nikada nemam gotov projekat ispred sebe. Uvek se to radi "u hodu".
Osim 1. i 2. slučaja (po Marfiju) uvek ću imati još bar desetak slučajeva i za koju varijantu ću se onda odlučiti?
Naravno za drugu varijantu sa posebnim primarnim ključem kroz jedno polje i dodatna dva polja za veze,
...i još pregršt drugih polja koja će se u međuvremenu javiti.
...Ko zna možda ću toj tabeli pridružiti još jednu tipa 1:1, čisto da razdvojim neke sasvim druge podatke

Ponekad praksa diktira pravila koja u trenutku kreiranja nisu ni praktična i po performansama opravdana, jednostavno ti se "učini" da je tako bolje, kasnije se pokaže da li si bio u pravu ili pogrešio.
 
Odgovor na temu

Radudzoni
Radoslav Jovanovic
Beograd

Član broj: 8384
Poruke: 133
*.ptt.yu.



Profil

icon Re: Teorija Vs. Praksa16.07.2006. u 22:00 - pre 185 meseci
Citat:
U ovom slucaju odluka o rasporedjivanju iz stvarnog sveta i njen atribut Radnik_ZadatakID postaju bitan deo sistema.

OK... Ja sam se neprecizno izrazio... Hteo sam da stavim akcenat na vezu "VISE PREMA VISE"... nebitno je sto je primer takav da su potrebni jos neki podaci u tabeli Radnik_Zadatak...

A sto se tice performansi kazu (prakticari) da se bolje performanse postizu ako ima taj (nepotrebni) kljuc, bar je tako u Accessu zbog neznamtijacega...

 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.tippnet.co.yu.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Teorija Vs. Praksa16.07.2006. u 22:48 - pre 185 meseci
I za veze N:M i za 1:1 koristim kompozitne kljuceve bez obzira da li ce te veze dalje ucestvovati u novim vezama (i te nove veze bih napravio upotrebom kompozitnih kljuceva).

Ja ne uvodim u bazu atribute koji nemaju opravdanje u stvarnom sistemu.
- Pitam seku iz kadrovske: "Sta je to radnik zadatak id?". Posto nema pojma zakljucujem da je taj atribut nepotreban u bazi.
- Pitam je "Sta je to datum zaposljavanja?". "To je datum kada je radnik stupio u radni odnos sa nasom firmom. Od tog datuma mu vaze beneficije i peneli koji proizilaze iz ugovora o radu." Oho, pa seka zna sta je to datum zaposljavanja, te definitivno ovaj atribut mora naci svoje mesto u bazi.
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 00:09 - pre 185 meseci
@Radudzoni
Gledajući samo vezu N:M nema načina da se performanse poboljšavaju dodatnim ključem.
Jedino što je moguće da ako se upit izvršiš nad jednim delom opsega (ili RadnikID ili ZadatakID) kompozitni indeks daje lošije rezultate od pojedinačnog što u slučaju redovnog korišćenja N:M nije slučaj.
Dakle, ako su razlog samo performanse slobodno zadrži kompozitni ključ.

Ipak @chachka, u praksi:
- Završiš sa sekom i napraviš Radnik_Zadatak(RadnikID, ZadatakID)
- Kad završiš sa sekom javi ti se šef koji do tada nije imao vremena da sa tobom priča i kaže da želi da zna kada je određeni zadatak neki radnik započeo a kada završio. OK. Radnik_Zadatak(RadnikID,ZadatakID,DatumPocetak,DatumKraj)
- Posle nekog vremena javlja ti se zadovoljni šef koji bi hteo da opis toga šta je radnik uradio u određenom zadatku. OK. Radnik_Zadatak(RadnikID,ZadatakID,DatumPocetak,DatumKraj,Opis)
- Već poznati šef je smislio da se takvi procesi mogu rasparčati u više delova, svaki ima svoj početak, kraj i opis urađenog posla, ako može i da se doda status radnikovog zalaganja na određenom zadatku.
- itd

Moglo je ovo da se i dalje radi kompozitnim ključem ali je ovde svakako pitanje i performansi i jednostavnosti upita i same baze.
Ova projekcija baze je mogla ići i drugim tokom, možda kvalitetnijim, možda sa više tabela, i možda sa još dodatnih N:M veza.
Moglo se desiti da imaš gotov projekat i TAČKA. Nema dalje.
Moglo se desiti da odbiješ šefove zahteve ili da ih on jednostavno nema.
Jedino što dobro znam da su mi takve tabele PRE bile oblika (RadnikID,ZadatakID) a SADA su (ID,RadnikID,ZadatakID,...).

Meni je uvođenje ovog atributa sasvim opravdano u stvarnom svetu. Ne vidim razlog zašto bi neko ko projektuje baze uvodio atribute koje nemaju opravdanje u stvarnom svetu.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.tippnet.co.yu.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 07:36 - pre 185 meseci
Citat:
amladjo:
- Završiš sa sekom i napraviš Radnik_Zadatak(RadnikID, ZadatakID)
- Kad završiš sa sekom javi ti se šef koji do tada nije imao vremena da sa tobom priča i kaže da želi da zna kada je određeni zadatak neki radnik započeo a kada završio. OK. Radnik_Zadatak(RadnikID,ZadatakID,DatumPocetak,DatumKraj)
- Posle nekog vremena javlja ti se zadovoljni šef koji bi hteo da opis toga šta je radnik uradio u određenom zadatku. OK. Radnik_Zadatak(RadnikID,ZadatakID,DatumPocetak,DatumKraj,Opis)
- Već poznati šef je smislio da se takvi procesi mogu rasparčati u više delova, svaki ima svoj početak, kraj i opis urađenog posla, ako može i da se doda status radnikovog zalaganja na određenom zadatku.
- itd


Slazem se. Posle sefa dodje direktor, pa se i vlasnik setio neceg novog i korisnog, a na kraju dodje drzava i promenom zakona razbuca sve.

To je sve stvar buducnosti, a u sadasnjosti imamo samo Radnika i Zadatak. Kada se pojavi sef sa novim zahtevima, tada cu ponovo sagledati dizajn baze i mozda potpuno odbaciti tabelu Radnik_Zadatak ili je prosiriti ili joj promeniti kjluc (DROP CONSTRAINT, ADD COLUMN, ADD CONSTRAINT). Iskustvo mi pomaze da kazem: "Smatram da ce nam datum_pocetka_izvrsavanja_radnog_zadatka trebati u buducnosti.", ali ne znaci da ce se to i desiti.

Da li se secate divljackog poreskog sistema iz 96, 97? Savezni porez, republicki porez, porez za zeljeznicu, poseban porez na teritoriji Beograda, porez za vojsku, takse, preneti porezi, porez na promet usluga, porez na promet dobara. Da li je makar jedan program bio pripremljen 92 za takvo oporezivanje? Nije. Kada je nastala ta situacija programi su se prilagodjavali.

Dakle, kada se pojavi sef sa zahtevima, tada cu prilagodjavati model.
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 09:42 - pre 185 meseci
Citat:
chachkaa li se secate divljackog poreskog sistema iz 96, 97? Savezni porez, republicki porez, porez za zeljeznicu, poseban porez na teritoriji Beograda, porez za vojsku, takse, preneti porezi, porez na promet usluga, porez na promet dobara. Da li je makar jedan program bio pripremljen 92 za takvo oporezivanje? Nije. Kada je nastala ta situacija programi su se prilagodjavali.

Eh, to su bila vremena.
Sad me podseti da meni u tabeli poreskih stopa još stoji Stopa1 do Stopa5, možda se ti silni porezi vrate
No, šalim se, ovo je čisti nemar.
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 10:15 - pre 185 meseci
Citat:
amladjo:
...da se takvi procesi mogu rasparčati u više delova, svaki ima svoj početak, kraj i opis urađenog posla, ako može i da se doda status radnikovog zalaganja na određenom zadatku


Da, ovo je odlican primer kada ce primarni kljuc od dva polja da bude problem. Ako je za ojkedinacni posao potrebna evidencija koje su operacije potrebne, koji alati, koji materijali i slicno, mnogo je jednostvnije da id posla bude jedno polje nego kombinacija radnik + zadatak.

Citat:
chachka:
Ja ne uvodim u bazu atribute koji nemaju opravdanje u stvarnom sistemu.
- Pitam seku iz kadrovske: "Sta je to radnik zadatak id?". Posto nema pojma zakljucujem da je taj atribut nepotreban u bazi.
- Pitam je "Sta je to datum zaposljavanja?". "To je datum kada je radnik stupio u radni odnos sa nasom firmom. Od tog datuma mu vaze beneficije i peneli koji proizilaze iz ugovora o radu." Oho, pa seka zna sta je to datum zaposljavanja, te definitivno ovaj atribut mora naci svoje mesto u bazi.


Citat:
chachka:
Dakle, kada se pojavi sef sa zahtevima, tada cu prilagodjavati model.


Cacka, bez ljutnje, ali ovakav pristup pokazuje neiskustvo.

Sasvim je normalno da u ima mnogo polja za koja korisnik aplikacije ne mora uopste da ni dapostoje a kamoli da zna kakva im je svrha.

Model baze se ne menja tek tako, zbog toga je neophodno da se pre projektovanja sagledaju sve potrebe i model napravi tako da ih ispuni, a ako postoje potrebe koje u datom momentu ne mogu da se artikulisu, treba ih prepoznati kao takve i u modelu ostaviti prostor da se moze prosiriti bez velikih intervencija. Najvaznje je obezbediti da prosirenja baze ne menjaju postojece relaciej izmedju tabela, vec da se uglavnom svode na dpodavanej novih polja ili celih novih tabela sa novim relacijama koje se uklapaju u postojeci model.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.tippnet.co.yu.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 11:39 - pre 185 meseci
Citat:
broker:
Cacka, bez ljutnje, ali ovakav pristup pokazuje neiskustvo.

Neljutim se, jer se uvek prica izmedju muskaraca svodi na to ko ima veci.

Citat:
broker:
Sasvim je normalno da u ima mnogo polja za koja korisnik aplikacije ne mora uopste da ni dapostoje a kamoli da zna kakva im je svrha.

Normalno je da postoji masa parametara koji sluze radu aplikacije, radu Windows-a, radu kompjutera, ali su ti parametri u sluzbi resavanja problema, a nisu deo samog problema (sistema koji se automatizuje).

Baze podataka su i nastale kao potreba za nezavisnoscu podataka od aplikacija.

Citat:
broker:
Model baze se ne menja tek tako, zbog toga je neophodno da se pre projektovanja sagledaju sve potrebe i model napravi tako da ih ispuni, a ako postoje potrebe koje u datom momentu ne mogu da se artikulisu, treba ih prepoznati kao takve i u modelu ostaviti prostor da se moze prosiriti bez velikih intervencija. Najvaznje je obezbediti da prosirenja baze ne menjaju postojece relaciej izmedju tabela, vec da se uglavnom svode na dpodavanej novih polja ili celih novih tabela sa novim relacijama koje se uklapaju u postojeci model.

Kazes urbanisti Uzica:

"Majstore ovo je dosadasnji urbanisticki plan grada. Nesmes da srusis ni jednu zgradu, ni jednu kucu. Namoj slucajno da izvadis drvo, ako ti zasmenta pri izgradnji puta. Mozes da dodajes nove zgrade i puteve na periferiji grada, mozes da farbas postojece zgrade u raznim bojama, da krpis puteve i da zalivas parkove."

"Usput posto mi neznamo sta hocemo, isplaniraj ti nama lepo i prostor za metro, i fudbalski teren koji prima 200.000 posetilaca, i prostor za nuklearnu centralu, i kosmodrom koji je veci od NASA-inog, jednom recju isplaniraj ti nama SVE."

"I nemoj da gresis u projektovanju, jer cemo ti posle dozvoliti samo da menjas boju crepa na krovovima, a ako bas imas potrebe, velikodusno cemo ti dozvoliti da naknadno odredis prostor za jos jednu policijsku stanicu."

"To sto sada isplaniras MORA da traje 15000 godina, ima da nadzivimo i Keopsovu piramidu."

Sta ce ti urbanista na to odgovoriti?
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.neobee.net.



Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 12:46 - pre 185 meseci
Citat:

"Majstore ovo je dosadasnji urbanisticki plan grada. Nesmes da srusis ni jednu zgradu, ni jednu kucu. Namoj slucajno da izvadis drvo, ako ti zasmenta pri izgradnji puta. Mozes da dodajes nove zgrade i puteve na periferiji grada, mozes da farbas postojece zgrade u raznim bojama, da krpis puteve i da zalivas parkove."

"Usput posto mi neznamo sta hocemo, isplaniraj ti nama lepo i prostor za metro, i fudbalski teren koji prima 200.000 posetilaca, i prostor za nuklearnu centralu, i kosmodrom koji je veci od NASA-inog, jednom recju isplaniraj ti nama SVE."

"I nemoj da gresis u projektovanju, jer cemo ti posle dozvoliti samo da menjas boju crepa na krovovima, a ako bas imas potrebe, velikodusno cemo ti dozvoliti da naknadno odredis prostor za jos jednu policijsku stanicu."

"To sto sada isplaniras MORA da traje 15000 godina, ima da nadzivimo i Keopsovu piramidu."

Sta ce ti urbanista na to odgovoriti?

Svidja mi se odgovor...
Citat:

Ne ljutim se, jer se uvek prica izmedju muskaraca svodi na to ko ima veci.

Slažem se s ovom konstatacijom...

Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+709 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 13:00 - pre 185 meseci
chacka, poređenje ti je samo prividno na mestu. Zna se otprilike verovatnoća, sa jedne strane da se proširi model ili dodaju neka informativna polja na tabelu (prilična) i sa druge strane da Užice naprasno započne svemirski program (zanemarljiva).
Nije jedina svrha baze nezavisnost podataka od aplikacije. Primarna svrha baze je brzo i pouzdano baratanje perzistentnim podacima.

Pri modeliranju baze uvek se pravi kompromis između realnog (seka iz knjigovodstva) i aplikativnog (bata programer) modela. Ako ja imam složeni ključ od 3 ili 4 polja i u svakom upitu sam prinuđen da pišem par dodatnih uslova u where delu, normalno je da ću da dodam surogat ključ. Ili ako se moj aplikativni model svejedno zasniva na jedinstvenom ključu, logično mi je da ga prenesem i u bazu.
 
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
*.it-austria.net.

Sajt: www.baze-podataka.net


+2 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 13:01 - pre 185 meseci
Citat:
broker: Model baze se ne menja tek tako, zbog toga je neophodno da se pre projektovanja sagledaju sve potrebe i model napravi tako da ih ispuni, a ako postoje potrebe koje u datom momentu ne mogu da se artikulisu, treba ih prepoznati kao takve i u modelu ostaviti prostor da se moze prosiriti bez velikih intervencija. Najvaznje je obezbediti da prosirenja baze ne menjaju postojece relaciej izmedju tabela, vec da se uglavnom svode na dpodavanej novih polja ili celih novih tabela sa novim relacijama koje se uklapaju u postojeci model.

chacka je uz opisnu analogiju dao odlican odgovor, a ja bih samo jos dodao, da u praksi jos nisam sreo bazu, ciji osnovni dio vremenom nije barem malkice promijenjen. Osim toga, koji poslodavac ce ti platiti da mu radis nesto prekompleksno i ono sta mozda nikad nece koristiti?

Proces poslovanja se mijenja vremenom, dodaju se nove stvari, izbacuju zastarjele i suvisne. Samim tim moras mijenjati i dizajn baze.

Cak i ako se server sa bazom mora resetovati, izmjene su katkad neminovne.

Brzi edit: Ja inace ne koristim kompleksne surogat kljuceve, jer zelim imati sto jednostavniji i pregledniji dizajn baze. Dakle, moja opcija bi bila:
Radnik_Zadatak(RadnikID, ZadatakID)

Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 13:26 - pre 185 meseci
Ljudi, ne ide nikuda ako svoje stanoviste zelite da dokazujete koristeci bukvalna tumacenja i drasticne primere koji samo naizgled imaju veze sa temom. Ako vi projektujete model sa stanovistem da nije bitno da li cete za neke inace sitne dorade morati ceo modela da preradujete, onda negde debelo gresite.

Sam stav "o tome cu da razmisljam kada se problem pojavi" je prilicno neobican za nekoga ko se predstavlja da zna da projektuje baze podataka.

Ja nisam pricao o korenitim promenama nego o nadogradnjama postojeceg modela koje bi trebale da budu bezbolne za postojeci sistem. Takve dorade projektant treba da predvidi, naravno ne bukvalno, nego nacelno i da u modelu ostavi prostor da moze da ih implementira a da ne prekraja ceo model.

Ako vam se desi da narucilac zatrazi nesto sto zahteva korenitu promenu na bazi to je ili znak da ste LOSE obavili svoj posao projektanta ili da naruciocu treba napraviti potpuno novu bazu jer se novi posao ne moze obaviti kroz staru bazu.

Prosto receno: svaka korenita izmena na modelu baze nakon sto je ona isprojektovana i realizovana je znak da je negde napravljena greska: ili narucilac nije dao dovoljno podataka u projektom zahtevu, ili projektant nije dovoljno dobro sagledao sve zadatke koje baza treba da obavlja.

 
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
*.it-austria.net.

Sajt: www.baze-podataka.net


+2 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 14:11 - pre 185 meseci
@broker: Sorry, ali ti kao da nemas prakse u dizajniranju baza podataka, nego sve govoris samo iz teorije, koja bi u svim slucajevima trebala biti idealna i u praksi, mislim ako si nesto procitao u knjizi, ne mora znaciti da se to mora i moze tako odraditi i u praksi.

Evo, navescu ti samo jedan primjer...

Za Telekom Austria je davno radjen kompletan OSS/BSS sistem zasnovan na Oracleu. Odredjeni dio aplikacija je radio u Perlu ili C-u (Pro C), a i nije bilo ADSL-a i ostalih novih tehnologija... Menadzeri i glavni projekt lideri su kreirali projektnu dokumentaciju i osmislili funkcionalnost sistema, trudeci se obuhvatiti/pokriti sto je moguce vise planiranih zahtjeva, ostavljajuci mjesta i fleksibilnim izmjenama. Godinama su se izvrsavale sitne izmjene, takoreci "patch na patch". Ali tehnologija se mijenja, pa je i Telekom Austria morao promijeniti funkcionalnost svog sistema.

Kako god projektanti tada projektovali bazu, nemoguce je bilo isplanirati i pokriti sve moguce situacije obrade podataka. Prosle godine je zapoceta generalka - veliki dio sistema je poboljsan, prepravljen, izmijenjeno je nekoliko glavnih tabela, dodana je hrpa aplikativnog kôda (PL/SQL, Java i td.)...

Da samo znas, koliko su se prakticna rjesenja razlikovala od teoretskih...

Jedino sto se slazem je to, da takve velike izmjene treba posebno naplatiti, sto je ovom prilikom i dogovoreno. Jedno je ugovor o odrzavanju, a drugo je ugovor o velikim izmjenama u sistemu.

Brzi edit: Npr. u teoriji se navodi, da je dobro dizajnirana baza samo ona, koja ima nivo normalizacije veci od 2 (npr. 2 NF, 3 NF ...), ali iznenadio bi se koliko se denormalizacijom visoko normalizovanih tabela (sa 3 NF na 1 NF) dobija na performansama, pogotovo ako se radi o Data Warehouse sistemu, gdje su ucestali full table scanovi, pa je brze i optimalnije ucitati vise blokova odjednom IZ JEDNE TABELE nego slati upite ka vise normalizovanih tabela.
Ili slucaj, kada je u OLTP okruzenju pozeljno imati visoko normalizovane tabele...
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.dialup.neobee.net.



Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 14:38 - pre 185 meseci
Pozdrav,

samo jedan mali komentar...
Na fax-u nas uče teoriju i to ne baš nešto konkretno. Ali neke konkretne stvari,
kao projektovanje baze se ipak uči u praksi. Moj stav je sledeći, svaka čast
teoretskom znanju koje stičemo na fax-u, ali prednost ipak dajem ljudima koji
rade sa BP i imaju dugogodišnje iskustvo. A ako su još iskustvo stekli na nekim
velikim projektima, stvarno su majstori.
Ne trebamo pokazivati, ko ima veći, nego svojim argumentima ubediti zašto je nešto bolje
i nemati toliki ego da ne priznamo tu činjenicu...
Za mene, ako neko ima bolje, optimalnije rešenje je poklon jer tada stičem nešto novo
što nisam sam mogao skontati, naravno, ako me ubedi da je to stvarno bolje rešenje...

Nadam se da nisam izašao iz teme...
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 14:55 - pre 185 meseci
Dejane, ja pricam upravo na osnovu dugog niza godina prakticnog iskustva.

Uostalom, upravo primeri koje smo dali pokazuju da iskustva iz prakse navode na resenja koja nisu skolska i objasnili zbog cega.

Ti uporno navodis primere koji su predstavljaju drasticne izmene. Ja sam na terenu nebrojeno puta video baze podataka prepune zakrpa koje samo drze vodu, jer u osnovi sistem nije dobro osmisljen i nije bio fleksibilan za sitne izmene. Kad su krupne izmene u pitanju prica je sasvim druga, rasturis to sto imas i napravis iznova gledajuci da iskoristis podatke iz ranijeg modela. Ne mozes to porediti sa doradama modela o kojima mi ovde pricamo.

Uostalom, covek je pitao zasto postoje dva nacina resavanja problema na koji je naisao, i to mu je objasnjeno. Koji ce on da primeni zavisi od toga sta ce dalje biti sa tim modelom koji radi, a ne od necijih afiniteta.
 
Odgovor na temu

Zidar
Canada

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



+79 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 14:59 - pre 185 meseci
Citat:
Pri modeliranju baze uvek se pravi kompromis između realnog (seka iz knjigovodstva) i aplikativnog (bata programer) modela. Ako ja imam složeni ključ od 3 ili 4 polja i u svakom upitu sam prinuđen da pišem par dodatnih uslova u where delu, normalno je da ću da dodam surogat ključ.

Druga recenica iz citata objasnjava zasto se koriste surogatni kljucevi - zato sto progarmera mrzi da pise JOIN i WHERE po nekoliko kolona umasto po jednoj. Pa sta ako moras da pises par ddatnih uslova/ To je tvoj posao za koji si placen. tesko/ Tough luck. Uvodjenje surogat kljuca otvara vrata za nevidjene stvari. Recimo,

Zadaci (SurogatID PK, RadnikID, ZadatakID) dozvoljava da se za RadnikId=1 i zdatakID=5 odradi ovo:

INSERT INTO Zadaci VALUES (1,1,5)
INSERT INTO Zadaci VALUES (2,1,5)
INSERT INTO Zadaci VALUES (3,1,5)
INSERT INTO Zadaci VALUES (4,1,5)
INSERT INTO Zadaci VALUES (5,1,5)

Znaci, 5 redova, isti radnik, isti zadatak. i sve je OK, jer zaboga PK je unique. Naravno, ovo ne dozvoljavamo u praksi, pa onda dodamo jos jedan unique index (RadnikID, ZadatakID). Eto, nema vise duplikata. jeste, ali imamo i dva indeksa. jedan po SurogatID, verovatno je taj i CLUSTERED, i jos jedan (RadnikID,ZadatakID), kpji nije clustered. I gde je tu performance improvement? Viska polje, koje je INT ili cak LongINt, dva indeksa. jedino poboljsanje jeste sto je naoko progarmeru lakse da napise JOIN kao

JOIN ON Zadaci AS Z ON Z.SurogatID=NekaTabela.SurogatID

umesto

JOIN ON Zadaci AS Z ON Z.RadnikID=NekaTableaRAdnik.ID AND Z.ZadatakID = NekaTabela.ZadatakID

I naravno, NekaTable imala bi samo SurohgatID za vezu sa Zadaci. Eto ustede - jedno polje se migrira u child tabelu, umesto dva.

amislite tableu IstorijaZadatka u koju se belzi sta je i kada uradjeno na nekom zadatku. Parent table je Zadaci a child atbela je IstorijaZadatka.
Varijanta 1: IstorijaZadatka (SurogatID,DAtum,StajUradjeno)
Ptanje glasi: Prikazati sve sta je neki radnik uradio i akda je uradio.
Posto imamo samo SurogatID za vezu sa Zadaci, onda nam je nophodan kveri da nam pklaze KOJI ranik je odradio Jednostavan SELECT koji daje sta nam treba:

SELECT I.SurogatID, I.DAtum, I.StajUradjeno, Z.radnikID
FROM IstorijaZadatka AS I
JOIN Zadaci ON I.SurogatID=Zadaci.SurogatID

Varijanta 2: IstorijaZadatka (RadnikID, ZadatakID, Datum, Sta jeUradjeno)
U ovom slucaju nam NE TREBA kveri koji povezujeIstorijaZadatka sa Zadaci. Select bi zigledao ovako:

SELECT RadnikID, ZadatakID, Datum, Sta jeUradjeno
FROM IstorijaZadatka

SELECT je select neko ce reci. Da li bas? Otkad je SELECT koji ima JOIN brrzi od selecta koji nema JOIN?

Znaci, upravo kveri za koji sebi pokusavata da olaksate pisanje, nece vam ni trebati ako migrirate slozeni kljucu child tabelu. Lakse je ne pisati kveri uopste, nego pisati najjednostavniji moguci kveri. Eto, i programer profitira ako se migrira slozeni kluc :-)

Ovo nisam ja izmislio, E. Codd je jos pre trideset godina rekao da se migrira ceo PK iz parent u child tabele. Onda je neko ustvrdio da je to teoretisanje i da je brze raditi sa surogat kljucevima. Mozda je tako bilo pre trideset godina, kompjuteri su bili sporiji i diskovi skuplji.

Nazalost, bez surogata se ne moze. Ima situacija kada u realnom sistemu ne postoji nista sto bi jednoznacno odredilo red u tabeli. Na primer - kasa u samousluzi. Racun koji dobijete je modelovan tabelom StavkeRacuna. Nije dobro da su stavke racuna modelovane ovako:

StavkeRacuna (RacunID, ArtiklID,Kolicina) PK (RacunID, ARtiklID)

Zasto? Pa svaki artikl moze da se pojavi na racunu tacno jedamput. Ako je korpa velika, i kupili ste 10 identicnih jogurta, ne znaci da ce kasir da skenira jedan i onda unese kolicinu. Kasir skenitra svaki artikl. Znaci, za 10 identicnih jogurta treba 10 redova u tabeli. Tu nam treba nesto da dobijemo PK. Nekakav brojac artikala na racunu. Ako ne prikazujemo taj brojac na racunu (redni broj artikla) onda je OK da stavimo na primer neki identity koji ce da obezbedi jedinstvenost. Ali, ako nam treba brojac stavki, i da ide od 1 pa nadalje, onda opet ne moze surogat key, mora da se nekako obezbedi brojac od 1 do N.


 
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
*.it-austria.net.

Sajt: www.baze-podataka.net


+2 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 15:10 - pre 185 meseci
@Zidar: Da, u toj namjeni je surogatni kljuc itekako pozeljan. Medjutim, u slucaju Radnik i Zadatak surogatni kljuc ti ne treba, jer ne bi imalo smisla da jednom Radniku dodijelis 10 puta isti zadatak, zar ne? :)
Osim ako imas Radnika, koji npr. svakih sat vremena obavlja jedan te isti zadatak, pa zelis za svaku tu kombinaciju osigurati jedinstvenost...
No, kako god okrenes, sve se svodi na rjesenje individualne namjene...
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

[es] :: Baze podataka :: Teorija Vs. Praksa

Strane: 1 2 3 4

[ Pregleda: 20386 | Odgovora: 73 ] > FB > Twit

Postavi temu Odgovori

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