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

    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