You have a design flaw in your database, using timestamp as a unique ID. There really is no work around. You can't reliably keep using timestamps for unique IDs. As a rule, a unique ID should not be dependent on anything else and should not represent anything else aside from a unique id. For instance, social security number is a very poor choice for unique ids. Yes, it's unique (to a certain degree), but it relies on accurate data entry and it represents confidential information.
I always use an unsigned integer field with auto increment for my unique id fields. An auto increment field is really the only way to assure uniqueness.


One way or another you are going to have change the way you database works.
Sorry, but any other solution I can think will only buy you a little time, it won't solve the problem.



On Feb 12, 2004, at 12:30 PM, Craig Jackson wrote:


Hello People,

This is my first post to this list. I am having a bit of a problem that
Google doesn't seem to help with, and I'm not sure what part of Mysql
docs will help.

I have a very large web app that uses timestamp for unique IDs.
Everything was rolling fine until we started getting many users per
second, causing some of the unique IDs to not be unique -- users were
being assigned the same timestamp. Since the web app is so large we
don't want to change the method of assigning IDs as it would create a
major project.

I have looked at Locking and Insert Delay, but I'm not sure that will
help.

Does anyone have a suggestion? We are using 4.0.14 and ISAM tables and
PHP 4.3.

Thanks,
Craig Jackson

--
Brent Baisley
Systems Architect
Landover Associates, Inc.
Search & Advisory Services for Advanced Technology Environments
p: 212.759.6400/800.759.0577


-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]



Reply via email to