Baza

[JanSifrer]

Pozdravljeni, V datoteki baza2.sql smo napisali kodo za postavitev naše baze, in nas zanima, če je napisana v redu oziroma tako kakor to prikazuje ER diagram, ne bi radi namreč videli, da se nam kasneje pri projektu vse skupaj sesuje. :) Hkrati pa imamo za Vas še dve vprašanji in sicer v tabeli 'prodaja' (16. vrstica) imamo referenco na tabelo 'zaposleni', in nas zanima, če obstaja kakšna lahka rešitev kako preveriti oziroma doseči, da avto lahko proda samo prodajalec, oziroma ga servisira samo serviser? Drugo vprašanje: ali v primeru, da hočemo narediti, da nove avte lahko dodajaj samo lastnik avto hiše, ki je hkrati tudi prodajalec, ali moramo to v bazi kako drugače označiti, ali je dovolj da zgolj določimo oz. si zapovnemo njegov id oz. EMŠO, in bo potem ob prijavi imel malo več opcij, kaj lahko počne s našo aplikacijo? Pač razmišljali smo, da bi v tabelo 'zaposleni' dodali še ene stolpec oz. dva (serviser, lastnik) samo potem bi en stolpec (lastnik) bil skoraj povsod False, stolpca serviser in prodajalec pa bi nekako bila povezana (če ni serviser je prodajalec, torej če je en True je drugi False), in malo ne vemo kako naj dopolnimo to tabelo, da bo zadeva čim bolj pravilna.

Za odgovor se Vam že v naprej najlepše zahvaljujemo in lepo pozdravljeni!

[PirnovarA]

Prvo odgovor za bazo:

• Tabela zaposleni

  • telefon bi zaradi vodilnih nicel priporocal TEXT

• Tabeli "rabljeni" in "novi" bi zdruzil v eno, kjer bi dal kot default vrednosti za nov avto (torej 0km in 0 starost) (ali pa v tabeli "avto" povedal, ali je le ta rabljen ali ne v novem stolpcu). Ker imam trenutno obcutek, da se zakomplicira pri ugotovljanju, ali je avto rabljen ali ne, ker razen ce gres ugotavljati v kateri tabeli je, ne ves.

@jaanos mogoce kak drug predlog?

Drugace se mi zdi zasnova vredu.

Prvo vprasanje: Ena moznost je uporabiti stolpec prodajalec iz tabele "zaposleni" kot dodaten foreign key, in potem lahko dodate CHECK nanj. Druga moznost je custom funkcija, (osnovni primer https://stackoverflow.com/questions/3880698/can-a-check-constraint-relate-to-another-table). Lahko pa seveda to preverjate z if else izjavami ob vstavljanju, s cimer se izognete kompliciranju (vendar potem se zanasate, da so vneseni podatki vedno pravilni, torej da prodajalec proda.)

Drugo vprasanje: Oboje je vredu, cisto iz vidika lazjega morebitnega spreminjanja je verjetno boljse, da v bazi oznacite, kdo je lastnik (oz nivoje dostopa), potem pa v aplikaciji prilagajate glede na to. Mogoce lahko potem namesto stolpca prodajalec uvedete stolpec tip, kjer bo potem 1 predstavljal npr lastnika, 2 prodajalca, 3 pa serviserja (ali pa kar uporabite stringe namesto stevilk).

Ce imate se kaksno vprasanje, vprasajte :)

[jaanos]

Se v glavnem strinjam s @PirnovarA - bi pa še malo pokomentiral pri prvem vprašanju.

Ena nekoliko bolj "čista" rešitev bi bila ta, da bi namesto stolpca prodajalec v tabeli zaposleni imeli še dve tabeli prodajalec in serviser, ki imata samo en stolpec (ki je tudi sam glavni ključ) - referenco na glavni ključ tabele zaposleni (mimogrede, namesto EMŠO bi predlagal ID, lahko tipa SERIAL). Potem gredo ustrezne reference na eno od teh dveh tabel.

Slaba lastnost te rešitve je ta, da je lahko posamezna oseba hkrati prodajalec in serviser (ali pa nič od tega) - kar pa ni nujno narobe (če npr. lastnik ni nič od tega, bi to bilo čisto ustrezno). Poleg tega, da ni potrebno ubrati kakih naprednejših prijemov, je ta način čistejši tudi iz stališča, da imate na ta način naravno mesto za dodajanje atributov, ki so relevantni samo za prodajalce ali samo za serviserje, če bi se izkazalo, da je to potrebno.

[JanSifrer]

Pozdravljeni, najlepša Vama hvala za hiter odgovor! Sedaj smo popravili, in se nam zdi, da bi baza mora biti OK? (Smo se potem odločili, da bomo imeli samo eno tabelo za zaposlene in dve za avte).