• Just concentrate on the basics.

    1) Make sure the column datatypes are the smallest necessary to comfortably fit the data.
    2) Make sure you use date columns for dates, integer type columns for whole numbers that might have math done to them, VARCHAR when data width will vary, and NVARCHAR if you need to store more than one language.
    3) Make sure to use third normal form--basically, avoid repetition of columns in the table
    4) Make sure all your tables have a primary key, in other words, a column that identifies one and only one row of the table
    5) When creating tables that refer to other tables make sure you use the referred to table's primary key, and make sure the key is as physically small as possible. I like using integer identities myself, there's a lot of debate about the best primary keys though!
    6) Put indexes on all primary keys, and I would recommend on all foreign keys (references to other tables) as well.
    7) Don't forget to put constraints on your columns and (where appropriate) table constraints where you need to constrain two or more columns in a single rule.

    The whole point in table design is to not repeat data, to make access as fast as possible, and to allow the *database* to perform as much error prevention as possible. If you do it correctly you relieve the developer of a lot of busy work when it comes time to write the application. As a bonus you'll increase the trust that can be put in the data. After all, if SQL Server is enforcing the rules ALL applications have to follow them automatically.

    Schema design is an art more than a science, but as in all things you can cover 80% of the need with 20% of the tools! 😉