Avoid overloading Meaning to Existing Database Column

I’ve always found that when defining a database table it is always best to create a integer primary key, even if a unique key such as social security number, ISBN, or some other business value. Recently I had to go through the unpleasant process of updating a database table and associated scripts, resources, and code that had used a business attribute as the primary key but because of business requirements it was no longer unique and had grown to have different meanings. Because your business requirements will change, don’t use business attributes as primary keys for you database design. In addition, don’t overload attributes to more than one meaning. For example, the database that I was working with had a database column called Sequence that functioned as the primary key, the line number, and a workflow execution order to process the data. It is a source of confusion and bugs to overload one attribute to so many different meanings.

Related posts:

  1. Create SQL Server Database and Database Tables From a File
  2. Copy Records From One Database To Another
  3. Copy Data Between Two Database Tables
  4. Database Best Practices
  5. Query Managed Auto Increment
  6. Rails Book


One Response to “Avoid overloading Meaning to Existing Database Column”

Leave a Reply