Pomoc pri organizaciji baze

Pozdrav svima.


Molim nekog, ko ima malko vremena da pogleda sljedeci diagram i da mi kaze dal ovo ima smisla ili se treba nesto mijenjat/poboljsat.

Evo par komentara na prvi pogled sto mogu da skontam:
1. Nemoj porez da vezujes za artikal, imas ulazne i izlazne poreske stope (ovo znam iz prakse), vezuj ga za tabelu aprimka.
Eventualno postavi neki default porez na artiklu pa pozivaj tamo u aprimka

2. Jedinica mere ti je PO MENI cist visak imaces silnog posla sa JOINIMA bez preke potreba. stavi polje JM na aritklu (neka bude enumeracija) i bice ti lakse

eto to je na prvi pogled. Mislim da ces na primkama morati dodavati jos polja, korisnici imaju svakojake zelje, cestitke i pozdrave

pozdrav
nadam se da je malko pomoglo

Potpis

/*A sad odo` malo napolje*/

Kuzim ovo za porez i slazem se da bi tako bilo bolje. A za jedinice mjere mislim da cu ostavit ovako zbog eventualnog sortiranja po JM, konzistencije unosa (vise usera bi mogli jenu jedinicu mjere unesti na vise nacina: kom., komada, k.), pa mozda nekom nece pasati da pise komada nego hoce da pise kom. pa onda samo promijenis u tabli 'mjera' a ne da moras mijenjat u svakom artiklu.. i tak.


A neki dan mi je pala jedna druga ideja na pamet. Razmisljam da li bilo "bolje" napravit model sa vrstama dokumenta. Npr. sad imamo 3 vrste dokumenta ko sto se i vidi na diagramu:

primke->aprimke
racuni->aracuni
izdatnice->aizdatnice

a moglo bi biti:

dokumenti->adokumenti

s time da imamo jednu tablu u kojoj su vrste dokumenta:

recimo za racune = 001, za izdatnice = 120, za primke = 220 i onda koristimo tablu dokumenti za sve dokumente a vadimo i manipuliramo sa njima prema vrsti dokumenta.

Cini mi se da bi ovaj model mogao biti laksi za eventualno naknadno nadogradivanje baze. Recimo da ako zelimo dodati novu vrstu dokumenta, recimo "ponude" onda samo napravimo novu vrstu dok. 130 i picimo dalje... Isto bi bilo lakse vadit brojcano stanje po artiklu iz jedne table nego iz 3, 4 ili cak vise. Jel to tako ili nesto gadno grijesim:)?

Sto se tice ideje oko JM, kako hoces naravno. s tim sto mi na aplikaciji radimo
listu sta korisnik moze da unese i caos.


Sto se tice ove zamisli oko generickih dokumenata imas (naravno) dve strane medalje.

1. Prednost je sto lako dodajes nova dokumenta, sve ti je genericki i nadogradivo je je li....
2. Mane su: sto na svakom dokumentu imas neka zajednicka polja, a brdo polja se odnosi SAMO na ODREDJENI DOKUMENT
Primer je medjuskladisnica gde imas polja IZ MAGACINA, U MAGACIN (ova polja nemas na drugim dokumentima),
Ili uplate gde imas konta sa izvoda koja knjizis a nemas ih na drugim dokumentima....
tako da sa ovim nacinom dobijas tabelu koja ima gomilu polja gde (unija svih polja na svim dokumentima) imas jako puno NULL vrednosti.
Ovo ce ti napraviti haos sa pretragama i upitima (radice prilicno sporo).


Ovo povlaci i spor odziv upita pogotovo ako imas puno dokumenata.
Ovo sto ti hoces se u teoriji zove ŠUR (Šema univerzalne relacije),
ali je prilicno tesko ostvariva

Verovatno ce ti se javiti problemi sa gomilom SUBQUERY-ja
koji ce trcati po dokumentima i trazice dosta vremena.


Radi naravno kako zelis ali ti je ovo par opaski u sta mozes da se uvalis

pozdrav

Potpis

/*A sad odo` malo napolje*/