First, my source of confusion is why would you insert duplicate  data
into your database. You may need to check your object in the UI, if
applicable, and then insert  it into database.

Anyway, I wouldn't go for Hashing. The point is that you will have to
check your database  quite a few times to find the right id. The world
would be a better place if we could define a hash function that maps
our objects to unique  ids.

You could alternatively rely on your database auto numbering, but you
will need to put it in a stored procedure to check whether not the
record is already in database. Your database is indexed and a String
search is fast anyway. On top of that, putting this logic in the
database will give  you scalability at a minor cost. You always have
the option  to add another machine to the cluster if the performance
sucks.

Many Thanks for your reply, but there is no source of confusion.
when you are using auto number, insertion of duplicate  record happens alot.
besides, please consider that such preventions should not occur in UI at all, because of the severe performance  degradation in searching DB for every inserting  record. also, as benchmarks say, PK-String-search in a db will never be as fast as numeric  search.
of course as i said, in smaller  application you can choose this strategy and even using Hash Algorithms with String output  (such as SHA-1and MD5) would be good. but in larger ones, only Numeric PK is recommended.

tell me about your application. It helps a lot if I know how you have duplicate  records.

let me give  you a complete example:
suppose a table  of personnel information including the following fields.
id, firstname, lastname, father_name and age.
when you insert  data:
Jack, Smith, adam, 27
it will insert with an integer PK (like 987)
now if you accidentally insert those data  again, it will insert another record  with another PK (like 988) which is not desireable
now what I want is that I want to control generating primary  keys based  on the given data. I need a hash algorithm  which gives numeric  outputs as follows.
JackSmithadam27----->1025458218
JackSmithadam23----->1025498548
JackSmithadam27----->1025458218------->PK exist

this is where you define rule engines to avoid the load to be pushed on the db server or unnecessary code on UI.

your solution (hashing) might not be a better alternative to the first one (according to your email) and I don't think  if you end up with duplicate  PKs. but you might having different records  with different PKs but representing the same object. this is where you can use sequence in oracle or identity() in sql server to identify the object

most of the time you can let DB server to do the work by defining PK on columns. i.e. in sql server when you define a pk on multiple columns therefore the server will enforce uniqueness by generating unique  index for the pk columns. creation of the index involves some kind of hashing and it is a reliable and efficient technique. this is irrespective of the types of the pks (string or integer) but if columns contain null the ok generation function can ignore the content and still construct a unique key

still even for small scale applications, you might consider some light-weigth rule engine approach,

this defining PK on different columns seems quite an interesting way, but here 2 questions arise:
1- are these generated PKs integer?
2- can I apply this feature  in other databases? cause I use MySQL and I haven't yet encountered such a feature in it.

this defining PK on different columns seems quite an interesting way, but here 2 questions arise:
1- are these generated PKs integer?

Reply : This does not matter, but the only restriction is that the column that you are defining a PK for should not be NULL.

2- can I apply this feature  in other databases? cause I use MySQL and I haven't yet encountered such a feature in it.
Reply : As far as I know this is definitely supported by Oracle and SQL Server, I'm not too sure about MySQL.