Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. Database & SysAdmin
  3. Database
  4. Primary key

Primary key

Scheduled Pinned Locked Moved Database
12 Posts 6 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N netJP12L

    Hi, I have a Location table. I am wondering what should be its primary key.

    LocationTbl

    ID identity (1,1) not null
    LocationCode not null
    LocationName null
    LocationDescrption null

    Thanks

    N Offline
    N Offline
    Not Active
    wrote on last edited by
    #2

    Is this a trick question? Obviously the PK is the identity column.


    I know the language. I've read a book. - _Madmatt

    1 Reply Last reply
    0
    • N netJP12L

      Hi, I have a Location table. I am wondering what should be its primary key.

      LocationTbl

      ID identity (1,1) not null
      LocationCode not null
      LocationName null
      LocationDescrption null

      Thanks

      S Offline
      S Offline
      SilimSayo
      wrote on last edited by
      #3

      ID seems like an obvious choice but it won't have any meaningful info to end users. If LocationCode is unique and is meaningful to users, I would choose it as the primary key.

      J 1 Reply Last reply
      0
      • S SilimSayo

        ID seems like an obvious choice but it won't have any meaningful info to end users. If LocationCode is unique and is meaningful to users, I would choose it as the primary key.

        J Offline
        J Offline
        Jorgen Andersson
        wrote on last edited by
        #4

        I think you're missing the point with the primary key. It should never be visible to the end users!

        "When did ignorance become a point of view" - Dilbert

        C 1 Reply Last reply
        0
        • J Jorgen Andersson

          I think you're missing the point with the primary key. It should never be visible to the end users!

          "When did ignorance become a point of view" - Dilbert

          C Offline
          C Offline
          Corporal Agarn
          wrote on last edited by
          #5

          I do not agree that the primary key should never be visible to the end user but it is not a must have.

          J 1 Reply Last reply
          0
          • N netJP12L

            Hi, I have a Location table. I am wondering what should be its primary key.

            LocationTbl

            ID identity (1,1) not null
            LocationCode not null
            LocationName null
            LocationDescrption null

            Thanks

            C Offline
            C Offline
            Corporal Agarn
            wrote on last edited by
            #6

            As stated the ID should be your primary key with indexing on the LocationCode and possibly LocationName depending on criteria used to query the data.

            N 1 Reply Last reply
            0
            • C Corporal Agarn

              As stated the ID should be your primary key with indexing on the LocationCode and possibly LocationName depending on criteria used to query the data.

              N Offline
              N Offline
              netJP12L
              wrote on last edited by
              #7

              Thanks fellows for replying to my post. I had no intenions to trick you. It just sometimes little things create a confusion. I think, I am going to keep LocationCode unique. So, would you say i shouldn't keep ID (an identity column) in my Location table at all?

              C L 2 Replies Last reply
              0
              • N netJP12L

                Thanks fellows for replying to my post. I had no intenions to trick you. It just sometimes little things create a confusion. I think, I am going to keep LocationCode unique. So, would you say i shouldn't keep ID (an identity column) in my Location table at all?

                C Offline
                C Offline
                Corporal Agarn
                wrote on last edited by
                #8

                The ID column is a good idea. I would suggest you keep it.

                1 Reply Last reply
                0
                • C Corporal Agarn

                  I do not agree that the primary key should never be visible to the end user but it is not a must have.

                  J Offline
                  J Offline
                  Jorgen Andersson
                  wrote on last edited by
                  #9

                  One of the key requirements for a primary key is that it must not change over time, and one of the best ways to achieve this is to use a surrogate key. Preferably an integer as most databases are tuned for queries on integers. As it's only a part of the plumbing, the surrogate key has no need to ever be visible outside the DB. In particular, it should never be revealed to the user. This allows the DB administrator to change the representation of the keys at will if necessary. I can think of very few circumstances when there's a sense in making a key visible to the end user. For example when it's used as a parameter in webpage request.

                  "When did ignorance become a point of view" - Dilbert

                  L N 2 Replies Last reply
                  0
                  • J Jorgen Andersson

                    One of the key requirements for a primary key is that it must not change over time, and one of the best ways to achieve this is to use a surrogate key. Preferably an integer as most databases are tuned for queries on integers. As it's only a part of the plumbing, the surrogate key has no need to ever be visible outside the DB. In particular, it should never be revealed to the user. This allows the DB administrator to change the representation of the keys at will if necessary. I can think of very few circumstances when there's a sense in making a key visible to the end user. For example when it's used as a parameter in webpage request.

                    "When did ignorance become a point of view" - Dilbert

                    L Offline
                    L Offline
                    Luc Pattyn
                    wrote on last edited by
                    #10

                    I agree. :)

                    Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


                    I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.


                    1 Reply Last reply
                    0
                    • N netJP12L

                      Thanks fellows for replying to my post. I had no intenions to trick you. It just sometimes little things create a confusion. I think, I am going to keep LocationCode unique. So, would you say i shouldn't keep ID (an identity column) in my Location table at all?

                      L Offline
                      L Offline
                      Luc Pattyn
                      wrote on last edited by
                      #11

                      If locationCode gets its values assigned by someone external to the system, then it should NOT be used as the PK of your table. Primary Keys must be yours, and yours alone. So nobody can entice you to suddenly change their values. :)

                      Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


                      I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.


                      1 Reply Last reply
                      0
                      • J Jorgen Andersson

                        One of the key requirements for a primary key is that it must not change over time, and one of the best ways to achieve this is to use a surrogate key. Preferably an integer as most databases are tuned for queries on integers. As it's only a part of the plumbing, the surrogate key has no need to ever be visible outside the DB. In particular, it should never be revealed to the user. This allows the DB administrator to change the representation of the keys at will if necessary. I can think of very few circumstances when there's a sense in making a key visible to the end user. For example when it's used as a parameter in webpage request.

                        "When did ignorance become a point of view" - Dilbert

                        N Offline
                        N Offline
                        Not Active
                        wrote on last edited by
                        #12

                        Well said.


                        I know the language. I've read a book. - _Madmatt

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • World
                        • Users
                        • Groups