Need advice on preventing duplicate entries in People table

Question

Hi,
In my database, I have a "People" table where I store basic information about people e.g. PersonId, FirstName, LastName, Gender, etc.
There will be lots of entries made into this table and I want to prevent duplicate entries as much as humanly possible. I'd appreciate some pointers on what I should do to minimize duplicates.
My primary concerns are:
Duplicate entries for the same person using the person's full name vs. given name e.g. Mike Smith and Michael Smith
Making sure that two separate individuals with identical names do get entered into the table and get their unique PersonId's.
Not even sure how I can even possibly know if two individuals with identical names are two different people without having additional information but I wanted to ask the question anyway.
Thanks, Sam

Answer 1

Thank you all very much for your responses.
There are three separate issues/points here.
It is clear that it is impossible to prevent duplicates using only a person's first, middle and last names. Once I rely on an additional piece of information, then things get "easier" though nothing is bullet proof. I felt that this was self evident but
wanted to ask the question anyway.
Second issue is "potential" duplicates where there are some variations in the name e.g. Mike vs Michael. I'd like a bit more advice on this. I assume I need to create a table to define variations of a name to catch potential duplicates.
The third point is what Celko brought up -- rather nicely too :-) I understand both his and Erland's points on this as typical relational DB designs usually create people/user tables based upon their context e.g. Employees, Customers, etc.
I fundamentally disagree with this approach -- though it is currently the norm in most commercial DB designs. The reason for that is that it actually creates duplicates and my point is to prevent them. I'm going for more of an object based approach in the DB
design where a person is a person regardless of the different roles he/she may play and I see no reason in repeating some of the information about the person e.g. repeating first, last name, gender, etc in both customer and employee tables.
I strongly believe that all the information that are directly related to a person should be kept in the People table and referenced in different business contexts as necessary.
For example, I assign every person a PersonId in the People table. I then use the PersonId as part of the primary key in the Customers or Employees table as well. Obviously, PersonId is also a foreign key in Customers and Employees tables. This prevents the
need for a separate CustomerId and allows me to centralize all the personal data in the People table.
In my opinion this has three advantages:
Prevent duplication of data
Allow global edits e.g. if the last name of a female employee changes, it is automatically updated for her within the context of "Customer" role she may play in the application.
Last but not least, data enrichment where a person may enter additional data about himself/herself in different contexts. For example, in the employee context, we may have the person's spouse information through "Emergency Contacts" which may come handy
within the context of customer for this person.
Having everyone in the People table gives me these three advantages.
Thanks, Sam