What are some of your most useful database standards?

Answer 1

In addition to normalization to 3NF or BCNF (more about that in this question), I have found the following to be useful:

• Name tables as plural nouns
• Name columns as sigular

So a "People" table has a "PersonID" column.

• There is nothing wrong with composite keys, so long as the rules of 3NF or BCNF still hold. In many cases (such as the "many-to-many" case) this is entirely desirable.
• Avoid repeating the table name in the column names. peoplePersonID is better written as table.column anyway, and much more readable and therefore self-documenting. People.PersonID is better, to me at least.
• ON DELETE CASCADE should be used very carefully.
• Remember that NULL means one of two things: Either it's unknown or it's not applicable.
• Remember also that NULLs have interesting affects on joins, so practice your LEFT, RIGHT, and FULL outer joins.

Answer 2

The most important standard is: don't have a database by default. I find too many developers grabbing a database for projects where life would have been much easier without one (at least yet). It is just a tool in the toolbox, and not every problem is a nail.

Inappropriate use of a database leads to anemic domain models, badly testable code and unneeded performance problems.

Answer 3

1. Don't use type names in the field names. The older guys will remember the old MS standard of lpszFieldName and the stupidity that ensued.

2. Use descriptive field names That follow normal language conventions. For example "FirstName" instead of "NameFirst"

3. Each word in the field name is capitalized

4. No underscores

5. Do not use normal keywords such as "Index"

6. Do not prefix ANYTHING with the object type. For example we do NOT use tblCustomers or spCustomersGet. These don't allow for good sorting and provide zero value.

7. Use schemas to define separate areas of the database. Such as sales.Customers and hr.Employees. This will get rid of most of the prefixes people use.

8. Loops of any kind should be viewed with suspicion. There's usually a better set based way.

9. Use views for complicated joins.

10. Avoid complicated joins when possible. It may be more astheticaly pleasing to have a CustomerPhoneNumbers table; but honestly, how many phone numbers do we really need to store? Just add the fields to the Customers table. Your DB queries will be faster and it's much easier to understand.

11. If one table calls a field "EmployeeId" then EVERY SINGLE TABLE that references it should use that name. It doesn't need to be called CustomerServiceRepId just because it's in an extension table.

12. Almost all tables have the "s" ending. For example: Customers, Orders, etc. After all the table holds many records...

13. Evaluate your queries, indexes and foreign key relationships with an analysis tool. Even those that may be generated for you. You might be surprised.

14. Linking tables which support many to many relationships have both linked tables in the name. For example, SchoolsGrades. It's very easy to tell by the table name what it does.

15. Be CONSISTENT. If you start down one path with your conventions, don't change horses halfway unless you are willing to refactor all of the previous work. This should put the brakes on any "wouldn't it be great if.." ideas that end up causing confusion and vast amounts of rework.

16. Think before you type. Do you really need that table, field, sproc, or view? Are you sure it isn't covered somewhere else? Get concensus before adding it. And if for some reason you have to take it out, talk to your team first. I've been at places where the DBA's make daily breaking changes without regard for the devs. This isn't fun.

Answer 4

I always try not to use the type in the field name - "sFirstName", "sLastName", or "iEmployeeID". While they match at first, if something changes, they'll be out of sync, and it's a huge headache to change those names later, since you have to change the dependant objects as well.

Intellisense and the GUI tools make it trivial to find out what type a column is, so I don't feel this is necessary.

Answer 5

Putting everybody's input together into one list.

Naming Standards

• Schemas are named by functional area (Products, Orders, Shipping)
  
• No Hungarian Notation: No type names in object names (no strFirstName)
  
• Do not use registered keywords for object names
  
• No spaces or any special characters in object names (Alphanumber + Underscore are the only things allowed)
  
• Name objects in a natural way (FirstName instead of NameFirst)
  
• Table name should match Primary Key Name and Description field (SalesType – SalesTypeId, SalesTypeDescription)
  
• Do not prefix with tbl_ or sp_
  
• Name code by object name (CustomerSearch, CustomerGetBalance)
  
• CamelCase database object names
  
• Column names should be singular
  
• Table names may be plural
  
• Give business names to all constraints (MustEnterFirstName)
  

Data Types

• Use same variable type across tables (Zip code – numeric in one table and varchar in another is not a good idea)
  
• Use nNVarChar for customer information (name, address(es)) etc. you never know when you may go multinational
  

In code

• Keywords always in UPPERCASE
  
• Never use implied joins (Comma syntax) - always use explicit INNER JOIN / OUTER JOIN
  
• One JOIN per line
  
• One WHERE clause per line
  
• No loops – replace with set based logic
  
• Use short forms of table names for aliases rather than A, B, C
  
• Avoid triggers unless there is no recourse
  
• Avoid cursors like the plague (read http://www.sqlservercentral.com/articles/T-SQL/66097/)
  

Documentation

• Create database diagrams
  
• Create a data dictionary
  

Normalization and Referential Integrity

• Use single column primary keys as much as possible. Use unique constraints where required.
  
• Referential integrity will be always enforced
  
• Avoid ON DELETE CASCADE
  
• OLTP must be at least 4NF
  
• Evaluate every one-to-many relationship as a potential many-to-many relationship
  
• Non user generated Primary Keys
  
• Build Insert based models instead of update based
  
• PK to FK must be same name (Employee.EmployeeId is the same field as EmployeeSalary.EmployeeId)
  
• Except when there is a double join (Person.PersonId joins to PersonRelation.PersonId_Parent and PersonRelation.PersonId_Child)
  

Maintenance : run periodic scripts to find

• Schema without table
  
• Orphaned records
  
• Tables without primary keys
  
• Tables without indexes
  
• Non-deterministic UDF
  
• Backup, Backup, Backup
  

Be good

• Be Consistent
  
• Fix errors now
  
• Read Joe Celko's SQL Programming Style (ISBN 978-0120887972)
  

Answer 6

Good database design and normalization.