Database Structure.. Ugg ?

Ok, So this may seem silly but I want to make sure I am right.

I have a simple enough database setup:

Table_Customer
  ID  (PK)
  Acc_number
  First
  Last
  etc.

Table_Notes
  ID (PK)
  Note_Type_FK (links to Table_Note_type)
  Note
  Account_FK (Links to Table_Customer)

Table_Note_Type
  ID (PK)
  Note_Type_Name
  Note_Type_Desc

Notesis for all notes relating to that customer and can be for tech s开发者_如何学编程upport, sales follow up, etc. This table has a FK linked to Note_Type and a FK back to Acc_number in Customer.

My Questions:

1. Is This set up correctly?
2. Using SQL, when I add/update a customer and select a note type (eg, Tech Support) and type in a note for that customer, is there anything I should be doing / watching out for when I run the insert statement ?

Its a simple question, but I want to make sure I am doing this correctly.

The setup seems correct for a simple CRM sort of software, but without the full system requirements, we can't answer if it is correct or not.

As far as inserting, as long as both the Customer and the Note_Type already exist, everything should be fine. The one thing that trips some people up at first is making sure the cascade rules are set the way they want them on the Foreign Keys. Depending on the requirements, you might want to have all Notes deleted when you delete a Customer (cascade delete), or you might want to require that all Notes are explicitly deleted first, before the Customer is allowed to be deleted (cascade restrict)

Your structure is correct, but you may want to rethink your naming scheme. Although naming schemes can vary widely, it's generally not considered good practice to prefix all your database tables with tbl or Table_. This article authored by Narayana Vyas Kondreddi seems to be one of the most widely accepted guides on SQL Server naming conventions:

http://vyaskn.tripod.com/object_naming.htm

The question of SQL naming conventions has also been answered on this site before, see:

Database Naming Conventions by Microsoft?

Your approach will work. One thing to mention; you don't need ID in customer table if account number is unique.

Here's a simple ERD for your purpose.