Pregledal sem vajin projekt in imam nekaj pripomb:
Imena entitet (in posledično tudi imena ustreznih tabel) se navadno pišejo v ednini - tako bi npr. bila ustrezna imena entitet Transakcija, Uporabnik, itd.
Password naj bo atribut pod uporabniki
Donatorje lahko združita s fake profili. Ena možnost je, da entiteti Fake profili in Donatorji združita z entiteto Uporabniki. Pri tem lahko dodata atribut "_tipuporabnika",
ki pove ali je uporabnik registriran, fake ali donator. Slednja dva lahko imata večina polj (geslo, username, naslov, ...) v tabeli kar NULL.
Morda dodata še podatek o tem, kdo je ustvaril kateri fake profil
Entiteto Tečajnica povežita direktno na entiteto Transakcije preko relacije (npr. Je v valuti).
Atributi na vajinih relacijah so nepotrebni, saj so zajeti že v entitetah.
Atribut "user id udeleženi" je morda nepotreben. Raje naredita več vnosov, kjer sta v vsaki vrstici le plačnik in prejemnik.
Smiselno je, da so vse entitete na nek način povezane.
Morda se lahko lotita transakcij na tak način, da jih ločita na račune in na transakcije znotraj računov (primer v Splitwise). To bi lahko zgledalo nekako takole:
id_racuna
tip_racuna
celoten_znesek
id_valute
dodal_racun
skupina/trip
opis
prejemnik
timestamp
1002345
1
600
154
ia3bb96g
Potovanje v Atene
letalske karte
eDreams
2018-04-26 21:45:33
tip_racuna -> Splitwise tipi transakcij
1 - Plača "placal" iz spodnje tabele, strošek se razdeli med vse
2 - Plača "placal", krije celoten strošek (ta tip lahko med drugim uporbita za donatorje)
itd.
Iz zgornje tabele lahko brišeš vnos, nato pa nastaviš cascade brisanje na spodnje vnose preko id_racuna
id_transakcije
znesek
placal
udelezeni/dolznik
id_racuna
1
300
ia3bb96g
ia3bb96g
1002345
2
300
ia3bb96g
j3k4aa9k
1002345
Takšna tabela je morda smiselna, saj se lahko tripu kasneje pridruži nov član, kar bi lahko pokvarilo izračune za nazaj
Na tak način lahko uvedeta morda tudi poseben tip računa (npr _tipracuna=3), kjer se račun razdeli po poljubnih deležih (ponovno, v Splitwise to zgleda tako), te pa zapišeta v posebno tabelo, na primer:
id_racuna
delež
placal
1002345
0.3
ia3bb96g
1002345
0.7
j3k4aa9k
Prosim, da svoj diagram še izvozita kot sliko in jo dodata v README.md, in sicer tako, da dodate sledečo kodo:
![ER diagram](Diagram1.png)
Pregledal sem vajin projekt in imam nekaj pripomb:
Imena entitet (in posledično tudi imena ustreznih tabel) se navadno pišejo v ednini - tako bi npr. bila ustrezna imena entitet Transakcija, Uporabnik, itd.
Password naj bo atribut pod uporabniki
Donatorje lahko združita s fake profili. Ena možnost je, da entiteti Fake profili in Donatorji združita z entiteto Uporabniki. Pri tem lahko dodata atribut "_tipuporabnika", ki pove ali je uporabnik registriran, fake ali donator. Slednja dva lahko imata večina polj (geslo, username, naslov, ...) v tabeli kar NULL. Morda dodata še podatek o tem, kdo je ustvaril kateri fake profil
Entiteto Tečajnica povežita direktno na entiteto Transakcije preko relacije (npr. Je v valuti).
Atributi na vajinih relacijah so nepotrebni, saj so zajeti že v entitetah.
Atribut "user id udeleženi" je morda nepotreben. Raje naredita več vnosov, kjer sta v vsaki vrstici le plačnik in prejemnik.
Smiselno je, da so vse entitete na nek način povezane.
Morda se lahko lotita transakcij na tak način, da jih ločita na račune in na transakcije znotraj računov (primer v Splitwise). To bi lahko zgledalo nekako takole:
tip_racuna -> Splitwise tipi transakcij
itd.
Iz zgornje tabele lahko brišeš vnos, nato pa nastaviš cascade brisanje na spodnje vnose preko id_racuna
Takšna tabela je morda smiselna, saj se lahko tripu kasneje pridruži nov član, kar bi lahko pokvarilo izračune za nazaj
Na tak način lahko uvedeta morda tudi poseben tip računa (npr _tipracuna=3), kjer se račun razdeli po poljubnih deležih (ponovno, v Splitwise to zgleda tako), te pa zapišeta v posebno tabelo, na primer:
![ER diagram](Diagram1.png)