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]