Rekommendation för primär nyckel

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Hyzac
    Medlem
    • 2004-03-03
    • 75

    #1

    Rekommendation för primär nyckel

    Ska skapa en databas för en enkel inloggningsfunktion för hyresgäster och undrar lite hur jag ska tänka kring den primära nyckeln i tabellen för given lägenhet och hyresgäst. Informationen till denna funktion kommer från andra system och grunden blir de tre kolumner i tabellen.

    Tabellen kommer bestå av lägenhetsnummer, epost och namn. Ett alternativ skulle vara att göra två tabeller av detta men då skulle lägenhetstabellen bestå av bara lägenhetsnumret då ingen annan information kring lägenheten finns tillgänglig samt att ingen mer information om hyresgästen finns som exempelvis hyresgästnummer.

    Det mest logiska är att rakt av sätta lägenhetsnummer som primär nyckel men då detta ska kopplas till en inloggningsfunktion där epostadressen kommer användas som identifierare undrar jag om även epostadressen bör vara inkluderad i den primära nyckeln då en epost få bara vara kopplad till ett lägenhetsnummer.

    Till denna tabell kommer det även kopplas en tabell med mätdata som bara kan kopplas till lägenhetsnumret vilket talar för att det bara är lägenhetsnumret som ska vara den primära nyckeln.

    Någon som har en rekommendation? Om inte epost ska vara med i den primära nyckeln finns det sätt att i databasen sätta begränsningar på att en epostadress bara får förekomma en gång?
    Last edited by Hyzac; 2010-12-17, 10:28.
  • erciz
    Medlem
    • 2001-05-07
    • 1880

    #2
    Lägenhetsnumret kan fungera, annars så kan du göra en ID-kolumn som du använder som primärnyckel, då får du en nyckel som inte är genererad av din data, se http://en.wikipedia.org/wiki/Surrogate_key

    Men kom ihåg att göra ett index på alla kolumner som du ska söka på och förekommer i WHERE-delen av din SQL, som t.ex. epostadressen.

    Comment

    • Lasp
      Medlem
      • 2000-07-29
      • 10197

      #3
      Du bör ju ha lägenhetsnummer unikt. Det kommer ju att vara olika lägenhetsinnehavare över tiden!
      Varje användare kan ju ha tillgång till en viss lägenhet under en period! Så ett datum för from och tom mellan lägenhet och användare är inte fel.
      Livet är kort och Nu!
      Läs mera!
      !?

      Comment

      • @nders
        Moderator
        Marsvin
        • 2000-06-30
        • 26914

        #4
        [citat]Om inte epost ska vara med i den primära nyckeln finns det sätt att i databasen sätta begränsningar på att en epostadress bara får förekomma en gång?[/citat]Sätt ett unikt index eller en constraint på fältet. Vet inte vilken dbms du använder, men: http://www.mssqltips.com/tip.asp?tip=1562

        Om fler personer ska kunna ha konto till en lägenhet hade jag satt nyckeln på lägenhetsnummer+email, och dessutom ha ett unikt index på emailadressen.

        mvh
        @aviddevguy

        Comment

        • Hyzac
          Medlem
          • 2004-03-03
          • 75

          #5
          Originally posted by Lasp
          Du bör ju ha lägenhetsnummer unikt. Det kommer ju att vara olika lägenhetsinnehavare över tiden!
          Varje användare kan ju ha tillgång till en viss lägenhet under en period! Så ett datum för from och tom mellan lägenhet och användare är inte fel.
          Tack för svaren. Tror att det bästa är att köra lägenhetsnummer som PK, det var den linjen jag var inne på från början men blev lite osäker då eposten spelar en viktig del i upplägget med. Blir lite speciellt upplägg då informationen som finns tillgänglig är begränsad.

          Comment

          Working...