Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 7678529
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 31, 20262026-05-31T17:40:07+00:00 2026-05-31T17:40:07+00:00

This is more a question of practical database design. I’ve designed smaller databases before,

  • 0

This is more a question of practical database design. I’ve designed smaller databases before, but nothing on the level of what I’m doing now (several million records), and I now need to consider efficiency and performance much more than I did before.

Consider the following: being given a large table with an ID# with 10 or so digits. This would of course be the primary key. From what I understand it’s bad practice to store the key as an integer unless you plan on doing math on it (please correct me if I’m wrong here). Is it best practice to store the key as a nvarchar(n) where n is the string length of the key? What about making your own primary keys (say an incremental key)? The size of the key would be smaller, but does it matter enough to detract from the fact that you can import data directly into the database that already has a relationship defined? (Importing a table with a foreign key from another table. Like a state code).

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-31T17:40:09+00:00Added an answer on May 31, 2026 at 5:40 pm

    It is a good practice to store the key as an integer unless you need leading zeros. You want the key to be the smallest size possible to make joins faster.

    Most databases have a way to set an incremental key automatically and if you want one, this tends to be the best way to do it unless you cannot afford to have any numbers missing in the sequnece due to rollbacks. There are really only few types of things that might have a leagl or regulartory requirement that you can’t skip items in a sequence, so the autogenerated id is one of the best choices if you want to use a surrogate key. Do not make your own incremental key unless you need to as you will not do this as efficiently as the database will do the automated key and if you get it wrong, you may have race conditions and the child tables could end up assigned to the wrong parent ID.

    If you have a guaranteed unique value (that is unchanging), you can use the natural key instead of a surrogate. It might slow down joins some, but it also might mean that you don’t have to do as many joins. However, if you use a natural key make sure it is in fact unique and that it will only rarely change. Things like person name,company name, email-address, etc are not good candiates for a antural key, automobile VIN number is. Remember you don’t want to change ten million child records because the company name changed.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

This is more of an academic inquiry than a practical question. Are there any
This is more a question of pros/cons between PHP and JAVA. Iv been doing
ASP.Net MVC3 is cool and all but I have this question more out of
This is more a general question but my particular case involves a ruby/rails app
this is more of a subjective Question, but I'll ask it anyway. I'm about
This is a moot question as I'm not on this project any more, but
This might be a very simple question, but more or less, I'm asking to
Pardon the elementary question but my newness to the realm of database design leaves
I'm not talking about making portable code. This is more a question of distribution.
This is more like a question of principle. I made a table with 100%

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.