dizajn baze - pomoć - početni koraci

Počinjem sa radom na jednostavnijim programu kojiće se vrlo vjerovatno poslije zakomplikovati (osnovna evidencija radnih naloga u firmi). Program bi trebao raditi kao web aplikacija na intranet-u.
Do sad sam radio jednostavnije do srednje složene 'aplikacije' u ms accessu, a ovo bi mi trebalo poslužiti kao nekakav primjer za učenje. Za back-end sam planirao uzeti postgres, a za freont-end (malo nespretan izraz) još nisam siguran (vjerovatno ću u početku koristiti access dok ne definišem dizajn baze).

Moje osnovno pitanje je koliko griješim na modelu iz priloga (šta trebam izmjeniti i zašto)?



Pošto planiram raditi sa postgres-om model je rađen u pgModeler-u.

Model je zakomplikovan time što je osnovni zahtjev da se mogu ispratiti sve izmjene nad pdatcima (osoba, datum i vrijeme, podatci) i da se može dobiti tačan izgled dokumenta kako je izgledao u određenom trenutku.

Dali se ovo može jednostavnije postići?

Drugo pitanje se tiče rada sa korisnicima (u ms accessu sam pravio tabele korisnika i grupa te preko toga definisao dostupne opcije ne koristeći interne accessove opcije):
Koji je preporučeni način rada sa korisnicima kod web aplikacija? - koja bi bila vaša preporuka za materijal na ovu temu (web, knjiga ...) po mogućnosti sa primjerima?

Svi savjeti i preporuke su dobrodošle.

Hvala!

Ovo nije prost zadatak. Pracenje izmena nije naivan posao i nije dobro izabran primer za ucenje, pogotovo samostalno. U skoli se uce baze podataka za staticne slucajeve - vaznio je ono sto je trenutno u bazi, a ne i istorija. U tvom slucaju vazna je kompletna istorija svega, sto je prakticno nemoguce. Moguce je pratiti delimicno istoriju ponecega, ali ne istoriju svega u svim tabelama. Nista od toga se ne uci u skoli, pa je bolje izabrati neki drugi primer.

Znam da ovo nije prost zadatak i da nije za učenje osnova ali smatram da osnove već dovoljno poznajem (bar što se dizajna baza i rada sa ms accessom tiče (SQL, vba i donekle VB) - koliko griješim ću najbolje vidjeti na primjeru).

Prije nekog vremena sam radio bazu u accessu gdje je bio sličan zahtjev ali se praćenje tražilo samo na 4 ne pretjerano komplikovane tabele, a prikaz promjena je bilo dovoljno uraditi za pojedinu stavku. Pošto je u ovoj bazi broj tabela koji se prate daleko veći interesuje me dali je ovo ispravan pristup i dali postoji jednostavniji način da se postigne praćenje? I dali promjene pratiti u posebnoj tabeli?
Vjerovatno će se ispostaviti na kraju da ovakvo praćenje treba na 20-40% tabeta (ostaje mi ubjeđivanje sa šefom), mada priznajem da me je problem zainteresovao.

Pretražujući web na ovu temu sam nailazio na članke gdje se ovo opisuje terminom "Extreme Auditing with Transaction History".
Možda bi bolje pitanje bilo dali je bolje (moguće?) iskoristiti Audit log i/ili Transaction log, ali pretpostavljam da bi to pitanje bilo bolje postaviti u Postgres forumu.

Hvala na komentaru i trudu (tvoje poruke na Access forumu su mi već duži niz godina zanimljivo i korisno štivo).

OK, svaka upornost treba da se nagradi

U MS SQL imas generalno dve opcije. Prva opcija prati promene na nivou kolone, a druga pravi kopiju izmenjenog ili obrisanog reda u nekoj _Hostory tabeli. Postoji i treca opcija, pracenje nekih vaznih kolona. Prve dve opcije su dva nacina zapisvanja istorije. Treca opcija zahteva potpuno razlicit pristup dizajnu baze jer se vise ne prate podaci nego same promene. Nije vise tabela sa podacima, nego tabela sa promenama. Komplikovano je pa cemo to ostaviti za neku drugu priliku.

Opcija 1:

Ako zelis pracenej ama bas svih promena na bilo kojoj tabeli, pogledaj ovaj clanak:
https://www.simple-talk.com/sq...q-no.5-pop-on-the-audit-trail/

Postoji jedna tabeal u koju se upisuju promene sa vise tabela, na nivou kolone. Tabela u koju se upisuje 'istorija' izgleda otprilike ovako: Tabela Audit: {ImeTAbeleKoajSePrati, PK_tabele_koja_se_prati, NazicvKolone, VrsataPromene, StaraVrednost, NovaVrednost, KojeOvoUradio, KadJeOvoUradjeno}
Zadrzi ime tabele 'Audit', iz prakticinih razloga.

Svaka tabela koju pratis treba da ima triger koji na INSERT, UPDATE, DELETE upisuje promenu u tabelu Audit. Sve sto treba da promenis u trigeru je ime tabele koju pratis. Triger radi ostalo. Ja na ovaj nacin partim promene u malim tabelama, koje se retko menjaju, ali promene mogu imati vazne posledice, pa je vazno znati sta se desavalo. Tabela Audit je prilicno nezgodna za pretrazivanje, pa ne koristim ovaj nacin za slucajeve kad se ocekuje mnogo promena i redovno pretrazivanje tabeel Audit. Resenje je ipak elegantno jer se svodi na cut/paste koda za triger (uz proemnu naziva tabele koaj s eprati).

Druga opciaj ti je da za svaku tabelu imas i history tabelu. Na primer, tabela People ima People_History tabelu. Sve kolone iz tabele People se nalaze i utabeli People_Hiostory. People_History treba da ima i dodate kolone:
ChangeType ('U','D'),
WhoDidIt (DEFAULT User_name),
HistoryTakenDate Datetime DEFAULT getDate()
RowCounre identity (1,1) PRIMARY KEY

Onda napises trigger za UPDATE i DELETE na tabeli People koji radi otprilike ovako:



Ovo lepo radi sve dok ne promenis tabelu People - dodas ili uklonis kolonu. Ako dodas kolonu u osnovnoj tabeli, a zaboravi da je dodas u Hostory tabeli, triger ce nastaviti da radi, ali se nece hvatati istorija za novu kolonu. Ako izbrses kolonu iz bazne tabele a ostavis je u history, triger ce da pukne pri prvoj promeni.

Na tabeli People_Hostuy treba da imas triger, za UPDATE i DELETE koji ima samo jednu nardebu -ROLLBACK koja sprecava brisanje i menjanje History tabele.

To je sva prica, u kratkim crtama.

Srecan rad

Izvinjenje zbog sporog odgovora (lični problemi).

Ne žurim sa ovim i za sad još uvijek nisam odlučio između jedna audit tabela za DB vs. audit tabela za svaku tabelu koja se prati vs. podatci ostaju u istoj tabeli, mada će najvjerovatnije biti kombinacija "podaci ostaju u istoj tabeli" za države, mjesta i partnere (jedan meni interesantan članak : Slowly changing dimension) i posebna audit tabela (ili tabela istorije) za svaku tabelu koja se prati.

Hvala!