Question: Using MS SQL: The scenario is I have already a Contact master table (tbl\_Customer)for all contacts in the company. The staffs suggested that they do not want to see all the contact and that they will only choose which contacts are applicable for them. The contact table is not gonna be store on the client like an outlook's pst file but on server side particularly on the database.

The methods i can use are:

1.) every time i add a staff i create a new independent table for the staff and the staff just adds the contact he/she needs from the master table via a program.

2.) I can change the contact master table to add say 50 fields with names staff01, staff02 and so on... I will make use of this fields as a marker that this rows of customer is a contact of the staff on the fields.

3.) I do a completely new contact list. Adds a field name "User". Mark the initial records via putting "ALL" on the field name. If a staff adds a contact, the table add a record with his/her name on the field "User". There will be an Auto numbered field as primary index.

Currently I'm tempted to use 3.) are there any other better method for my problem?

Answer: 
Why don't you have a staff table with a staff id - then every contact the staff in question wants can be a row in staffContacts. Column 1 is staffID and col 2 is contactID. Then you can join on the contact table to retrieve the details you want. 

The contacts table then only needs be updated...You only need to add one table with two columns. You may wish to impose constraints that let fields be entered that are unique to staffID and contact ID and are valid staff members and contacts. 
Nick.
In case many staff members have the same relevant contact - you should use a connection table, in which there will be 2 columns - one with the contact id , and one with the staff member id, use this table to query for staff's relevant contacts.

In case each contact has only one staff, than simply add a column with the relevant staff id, which will be a foreign key to the staff's table.

In any case and for other users to learn from: 

**method 1** you suggested is a big no no in SQL DB design, you need a really good reason for a DB with dynamically created tables. 

**method 2** is bad practice since most of the space will be wasted (unless defined as sparse columns but even though.. still space consuming) and also too specific - what will happen when you add a new staff member ? add a new column ? lock the whole DB for it and add many wasted space allocated?