ER-diagram / databasedesign

[nilsh]

Har laget et design som ser slik ut:

 

 

Tabellen bedrift er utgangspunktet her.

Man logger inn som en bedrift.

 

En bedrift har mange kunder

En kunde kan ha flere pumper

En pumpe kan ha mange servicer

 

Både kunder, pumper og servicer er derfor koblet til en bedrift, både indirekte og direkte..er det best kun å koble de indirekte?

 

Her har jeg inkludert bedriftid i alle tabeller for å lette på spørringene. Har bedriftid lagret i en session under hele oppholdet på websiden så det er enkelt å bruke denne i spørringer. Ser for meg mer kompliserte spørringer hvis jeg kobler kun indirekte..?

Mener det også blir sikrere i forhold til tilgang på andres kunder etc..?

 

Som her:

 

 

Tips og invendinger?

 

På forhånd: Tusen takk!

[quantum]

ta service-pumpe-bedrift: dersom du har en direkte kobling mellom service og bedrift åpner du for at en annen bedrift kan ta service på pumpa enn den som monterte den. om det er slik du vil ha det gjør du det slik. dersom det ikke er meningen, så betyr det at koblingen du innførte av «sikkerhetsmessige» årsaker faktisk åpner for inkonsistente data.

 

alternativt kan du legge inn en data_owner_id i alle tabeller, som *kun* brukes til å identifisere dataeierskapet, og *ikke* til å uttrykke noe som helst rørleggerbusinessmessig, som f.eks. hvilke kunde som har et kundeforhold til hvilket firma.

Endret 16. desember 2009 av quantum

[quantum]

ps, hva med kobling mellom montør og service og/eller pumpe? hvilken montør har utført service (eller skal utføre i fremtidig service)? hvilken montør har montert eller skal montere en gitt pumpe? er dette noe du har bruk for?

[nilsh]

Takk for respons!

 

Jo, det med montørene høres ut som en plan!

 

De direkte koblingene mellom bedrift og pumper og servicer.. Klarer ikke helt å se hvordan den direkte koblingen åpner for at bedrifter kan utføre servicer på pumper til en annen bedrifts kunde. Tenkte å inkludere i "alle" spørringer noe sånt som

AND `bedriftid` = '$bedriftid'

 

Det fungerer da kanskje mer som en slik "data_owner_id"-kolonne som du nevnte..?

 

Men denne skal altså ikke kobles sammen med den respektive bedriften vha. fremmednøkler..?

 

Uten denne data_owner_id: Hvis jeg da skal vise alle servicer utført av en bestemt bedrift, blir ikke det en noe komplisert spørring over flere (fire) tabeller?

 

Mange spørsmål.. =)

[quantum]

Takk for respons!

 

Jo, det med montørene høres ut som en plan!

 

De direkte koblingene mellom bedrift og pumper og servicer.. Klarer ikke helt å se hvordan den direkte koblingen åpner for at bedrifter kan utføre servicer på pumper til en annen bedrifts kunde. Tenkte å inkludere i "alle" spørringer noe sånt som

AND `bedriftid` = '$bedriftid'

 

Det fungerer da kanskje mer som en slik "data_owner_id"-kolonne som du nevnte..?

 

Men denne skal altså ikke kobles sammen med den respektive bedriften vha. fremmednøkler..?

 

Uten denne data_owner_id: Hvis jeg da skal vise alle servicer utført av en bestemt bedrift, blir ikke det en noe komplisert spørring over flere (fire) tabeller?

 

Mange spørsmål.. =)

 

Hvis du har en Pumpe og en Service som hører sammen og også har Service.bedrifts_id = 1, mens Pumpe.bedrifts_id = 2 så kunne det enten bety at pumpa er levert av en bedrift og service foretatt av en annen, eller at du har inkonsistente data. Bug or feature, who knows. Du bør ikke lage en datamodell som åpner for inkonsistens, medmindre du gjør det bevisst for å optimalisere ytelse. Men da bør du først ha funnet ut at du faktisk har ytelsesbehov som krever det. Eks, gitt at du har en service som er linket direkte til firma A, og indirekte til firma B via en pumpe. Hva gjør du da? Hvor mye hjelper egentlig dette deg?

 

Når det gjelder fremmednøkler så bruker du sef. det for å unngå inkonsistens, med rader som refererer til ikkeeksisterende firma. Hvorvidt det er en god idé med en owner_id eller ikke ... vel, tror det blir hipp som happ iom at modellen ikke er så stor. For å få litt bedre oversikt over behovet ditt kan du prøve å sette navn på relasjonene, f.eks. Pumpe-Levert-Av-Firma, Montør-Ansatt-i-Firma osv. Pointet mitt er at du kanskje bør skille mellom forretningsmessige relasjoner som de ovenfor, og mer «tekniske» av typen Data-Eid-Av, som du kan uttrykke med en owner_id i alle tabellene, HVIS du ser behovet for det. Det kan f.eks. være praktisk om hvert firma ønsker separat backup av sine data, da slipper du å forrholde deg til alle de forretningsmessige relasjonene i modellen for å lage et enkelt backup-script.

 

Jeg kan ikke helt se at du får problemer med for komplekse spørringer gitt de tabellene du har skissert dersom du skulle velge å ikke bruke «direktereferanser» i spørringene dine. Og dersom kompleksiteten øker vil jeg hevde at det å åpne for inkonsistens ved å innføre redundans er en veldig dyr pris å betale for å slippe å skrive et par-tre-fire ekstra joins. Inntil du ser det konkrete behovet ifm. ytelse, vel å merke.

[nilsh]

Ok, da skjønner jeg tegninga =) Takk!

 

Slik som dette ser det ut nå:

 

Hvordan skal en spørring se ut om jeg for eksempel vil finne alle servicer som er tatt av en bedrift? Dette må jo gå via pumper og kunder..

[quantum]

f.eks.

 

select s.ditt, s.datt 
from service s
inner join montor m on m.montor_id = s.montor_id
inner join bedrift b on b.bedrift_id = m.bedrift_id
where b.bedrift_id = 123

Endret 19. desember 2009 av quantum