Opbygning af database tabels til emails

1.  Du må have nogle tabeller du ikke nævner, såsom Author og To.

2.  Jeg går i det følgende ud fra, at en email kun kan være et sted (ad gangen).  Derfor foreslår jeg i tabel Email at tilføje et felt 'place'.  (Hvis det ikke holder stik, så sig til.)

3.  Så foreslår jeg, for at gøre det nemmere at forstå, i stedet for 'To' for eksempel at sige 'receiver'.  ToType bliver så receiverType.  Jeg går ud fra at en receiver kun kan have en receiverType.  Hans Jensen er enten et company eller en contact.  (Hvis det ikke holder stik, så sig til.)

4.  Under disse forudsætninger vil jeg foreslå en tabelstruktur som denne: http://christianjorgensen.be/simsen.PNG  (Jeg har forkortet nogle af dine titler.  For eksempel EmailPriority har jeg simpel hen kaldt Priority, og i stedet for emailPriorityId siger jeg blot id.  Det synes jeg gør det nemmere at have med at gøre.)

a.  Receiver er en adresseliste hvor hver receiver er af en bestemt type.

b.  En email har en priority og en author og er på en plads. 

c.  En email har en eller mange addressees.  Hver addressee er en receiver og er af en bestemt addresseeType Normal, CC, eller BCC.

I hver tabel er key'en angivet med en nøgle og linkene mellem tabellerne angiver foreign keys.

Hej Christian

Jeg tager det lige lidt efter lidt, og ser om jeg har forstået dig korrekt. Det håber jeg er ok med dig :-)

Hvorfor jeg ikke bare har forkortet nogle af navnene er fordi jeg bruger DB Visual Architect til at håndtere databasen og den brokker sig så meget, den ingenting vil før jeg har ændret det således at ingen felter har samme navn som tabelnavn. Men du bliver bare ved med dine navne - jeg tror godt jeg kan hitte ud af det.

Ad 1) Du har fuldstændig ret - som author har jeg en User tabel og til to har jeg så to tabeller nemlig en Company tabel og en Contact tabel.

Ad 2) Fuldstændig korrekt.

Ad 3) Du har ret at en receiver kan kun have én receiverType.

Ad 4a) Forstår jeg dig korrekt - når nu receiver er i to tabeller (Company og Contact) at jeg laver en receiverTypeId reference i begge tabeller?

Ad 4b) Ja det er helt korrekt.

Ad 4c) Igen korrekt forstået en email kan sendes til mange modtagere af forskellige typer.

Så det eneste jeg ikke lige har med, om du er klar over at receiver er i to tabeller og dermed kan der være overlap i id - men at receiverTypeId afgør hvilken af de to tabeller, der er tale om - nemlig Company og Contact tabellerne?

mvh
simsen

Ad Ad 4a.  Jeg foreslår IKKE at du skal have receiver i to tabeller.  Jævnfør mit billed (det så du vel) foreslår jeg, at du laver en (og kun en) receiver tabel.  Receiver har et felt receiverType som er fremmednøgle til tabellen ReceiverType.  Der er en 'en-til-mange' relation mellem receivere og receiver typer.  Hver receiver er af en type, hver type kan have mange receivere.  I øjeblikket har du to receiver typer, company og contact.  Hvem ved, om det engang i fremtiden bliver 'handy' med flere receiver typer såsom 'ven' (hvis contacts er for saglige øjemed,) 'clubmedlem' (hvis nogen i fodboldklubben, eller hvad du er med i, finder ud af hvad du roder med og vil genbruge dit program) og 'kæreste' (de vil nok altid være af BCC addresse typen.)  Med den foreslåede tabel struktur kan du udvide, for eksempel, antallet af receiver typer ved blot at lave flere linjer i ReceiverType tabellen.

I mit billed har jeg tegnet alle 'en' tabellerne, såsom receiverType, højere end 'mange' tabellerne, såsom receiver.  Stregerne mellem tabellerne angiver relationer, hvor stregen forneden ender i en fremmednøgle og foroven ender i hvad den er fremmednøgle til.  Du vil se, at der er flere niveauer af 'en-til-mange' relationer.  For eksempel, som allerede sagt, hver receiver er af en receivertype og hver receivertype bruges til mange receivers.  Samtidig er hver addressee til en receiver, men en receiver kan i tidens løb være addressee til mange emails.

Nå, den blev skudt af for tidligt.  Jeg var i færd med at rette den sidste paragraf til at sige, at i mit billed forestiller stregerne mellem tabellerne en-til-mange relationer hvor en streg forneden ender i en fremmednøgle og foroven ender i det den er fremmednøgle til.  (En-tabellerne er ikke i alle tilfælde tegnet højere end mange-tabellerne, men relationerne, stregerne, går altid fra fremmednøgle opad til det den er fremmednøgle til.

Du må undskylde hvis jeg virker lidt tungnem - men det her "problem" kommer af, det er en eksisterende database, hvor jeg så vil have tilføjet mulighed for at sende emails til de to typer Company og Contacts.

Altså det du foreslår er, at jeg laver en receiver tabel, hvor jeg så hver gang der oprettes en ny company eller contact smider den email adresse de har ned i receiver tabellen.

Det jeg så nu spekulerer på er, om det er i company/contact tabellen skal være en foreign key til receiver tabellen eller om det skal være omvendt?

Ok, jeg havde ikke forstået problemstillingen, som synes at være den følgende:  Du har en bestående database hvor du blandt andet har en tabel med Contacts og en tabel med Companies.  Du vil nu kunne holde rede på hvilke email der sendes til hvilke Contacts og hvilke Companies.  Et spørgsmål:  ER DET OGSÅ MENINGEN I SAMME OMGANG AT HOLDE REDE PÅ DE EMAILS DU MODTAGER?  Jeg antager for nu, at svaret er nej.  (Det kan måske komme senere.)

Jeg går så tilbage til dine tabeller i dit oprindelige spørgsmål.  Tabel Email får en række for hver email der er sendt hvorimod EmailMessageMapped tabellen får en række for hver email addressat.  Ikkesandt?  Hvis du har sendt 100 email til gennemsnitligt 10 adressater vil Email have 100 rækker og EmailMessageMapped cirka 1000 rækker.  Hvis det holder stik at en email kun kan være et sted ad gangen, så er  PlaceholderId er en egenskab ved emailen og hører den hjemme i Tabel Email, ikke i EmailMessageMapped.  Jeg ville så synes det bliver nemmere at forstå, hvis EmailMessageMapped tabellen i stedet kommer til at hedde Addressee eller sådan noget, og emailTypeId kommer til at hedde AddresseeType.  Normal, CC, og BCC er jo en egenskab ved addressaten, ikke en egenskab ved emailen.

Der er forskellige veje at gå.  En mulighed er at sammenføje contacts og companies i en enkel ny tabel som du kalder Receipients eller lignende og som har de samme felter som contacts og companies tabellerne har nu plus et felt emailadresse.  Contacts og Companies synes at være same slags 'ting,' nogen du holder kontakt med.  Det ville efter min mening være den mest fleksible løsning med best mulighed for udbredelse (såsom flere typer contakter) og de simpleste relationer til andre tabeller.  I så fald skal du i tabellen EmailMessageMapped/Addressee have en emailToId (som jeg ville kalde Receipient) og ingen emailToTypeId.  Det er det jeg har gengivet i mit billed http://christianjorgensen.be/simsen.PNG .

Hvis du ikke ønsker, eller ikke kan, gå i den retning, men vil fastholde de to tabeller Contact og Company, så kommer spørgsmålet, om disse tabeller indeholder et felt for email adresse for contakten, companyet eller om du kan/vil tilføje et sådant felt.  Hvis tabellerne har eller kan få et felt for email adresse, så skal du i EmailmessageMapped/Addressee tabellen have en bred foreign key bestående af to felter emailToId og emailToTypeId (eller receipientId og receipientType.  Hvis email nummer 25 går til contact nummer 3 som nomal, company nummer 7 som CC, og company nummer 12 som BCC, så kommer din Addressee (eller EmailMessageMapped) tabel til at se således ud:

Addressee
id email receiverid receivertype addresseetype
1      25      3      contact    normal
2      25      7      company    cc
3      25      12    company    bcc

Så kommer tabellerne til at se således ud: http://christianjorgensen.be/simsen2.PNG .  Det fremgår ikke så tydeligt af billedet at det i Addressee er receiverid og receivertype der tilsammen udgør foreign key.

Hvis du ikke har, eller ikke kan indsætte, email adresse i company og contact tabellerne, så kommer det på tale at oprette en tabel med email adresser og give tabellen felter for receipient id og receipient type.  Så flyttes den brede foreign key til receiver tabellen, og i EmailMessageMapped/Addresse tabellen behøver du kun receiverid som foreign key.  Her er et billed af den situation: http://christianjorgensen.be/simsen3.PNG

Hej igen Christian

Lige nu kører den øvre etage for nul brændstof. Så jeg håber du bærer over med, jeg først får det her testet af i morgen.

Det slår mig lige nu, at jeg ikke har fået en oplysning med til dig (jeg har slet og ret glemt den fandtes). Men det er således at i Company tabellen er der én email adresse - nemlig en arbejds mail adresse og i Contact tabellen er der to email adresser - en arbejds adresse og en privat adresse (altså email adresser).

Jeg har desværre ikke mulighed for at slå de to tabeller sammen, og det vil også blive for uoverskueligt, da begge tabeller kun har almindelige adresse og arbejds mail adresse ens - resten er vidt forskelligt.

Det jeg vil høre dig om, er at med udgangspunkt i simsen2.png, så
laver jeg en ny tabel, som jeg kalder et eller andet som eks. emailtype (der indeholder om det er en arbejds eller privat mail) og så smider foreing key på Addressee tabellen og den så bliver en sammensat nøgle med 3 nøgler: receiverid, receivertypeid, og emailtypeid.

Og så bliver det spændende hvordan jeg laver en sammensat foreign key - jeg ved hvordan jeg gør når det er primærnøgle men ikke fremmednøglen :-)

Og du skal endelig sige til, hvis du vil have flere points - jeg er meget taknemlig for din hjælp lige nu :-)