[Tutor] Generating unique ID

[Timo]

Thanks for all the answers.

I'm using SQLite as database and will try the ROWID.

Timo


Modulok schreef:
>> 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.
>
>   
>>> os.urandom(n)
>>>       
>
> 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
> them!
>
> 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
>>>> time.time()
>>>>         
> 1256796357.661967
>
> If it absolutely must be unique, use a database manager that can make
> that guarantee.
>
> Best of luck!
> -Modulok-
>