[Tutor] Generating unique ID
timomlists at gmail.com
Thu Oct 29 10:06:02 CET 2009
Thanks for all the answers.
I'm using SQLite as database and will try the ROWID.
>> I'm writing an application which will hold a database of people. Ofcourse,
>> people can have the same name, so I want to stock them with an unique ID.
>> I've searched and found some things:
>> - uuid.uuid4()
>> - id(name)
>> - os.urandom(n)
>> But they seem overkill to me. Well, maybe not id().
>> What should I use the best for this? Maybe examples of other programs that
>> do something alike?
> Use the auto-increment feature of your database database management
> backend. (Assuming you're using a database backend like MySQL,
> postgresql, etc.) In MySQL your database description would look
> something like this (with any other fields you need):
> # MySQL table description:
> CREATE TABLE IF NOT EXISTS mytable (
> `uid` BIGINT unsigned NOT NULL auto_increment unique,
> `uname` CHAR(32) NOT NULL default "guest",
> PRIMARY KEY (`uid`));
> You could use MySQLdb (third party python module) to talk to the MySQL
> process with Python. Other database managers have similar abilities.
> Random numbers are random, NOT unique.
> If you're using your own backend, like a text file or whatever, stop.
> Take the time to learn to use a database manager like postgresql or
> MySQL or whatever. They have already solved many of the problems
> you're now facing. It will be well worth the time and frustration.
> Otherwise, you'll have to parse your database and get the previously
> used value and then increment that. However, this solution will fail
> if there are multiple processes, or threads accessing the data
> concurrently. To solve that problem you'll have to introduce some
> manner of mutex to gurantee that only one process has access to the
> unique data at any given time. Things get complicated. All of these
> problems have already been solved with other database managers. Use
> In a pinch, with a low volume database for non-critical data, you
> could probably get away with using a Unix epoch style timestamp with
> sufficient granularity. But even this is in no way, "guaranteed" to be
> unique. It's just, "probably unique". It would look like this:
>>>> import time
> If it absolutely must be unique, use a database manager that can make
> that guarantee.
> Best of luck!
More information about the Tutor