Posted by Chung Leong on 11/25/01 11:47

nacho222@gmail.com wrote:
> I'm currently in the middle of writing a persistence framework, and I
> have to make a design decission. The framework will take care of all
> the saving and restoring objects, and also the relationships between
> them. Obviously, I need a way to identify objects uniquely. Now, one
> way would be to use an autogenerated id from a autoincremental field in
> the DB. But the problem is that I need to know the ID of the object as
> soon as it is created, to be able to relate it to other objects. So, I
> have come up with three possible solutions, none of which satisfies me.
>
> The solutions are (in my current order of preference):
> * A string ID, generated using uniqid. Main drawbacks: uniqid is a slow
> function, and having a string as a primary key raises an alarm in my
> head, as I tend to think (without any knowledge to back it up) that it
> would be somewhat innefficient.
> * An ID generated by an "ID manager", that serves IDs for each object
> creation. Main drawbacks: it would have to read the "next id" from the
> database for each request, and then update, as the manager can't be
> shared between concurrent requests. Two database queries per object
> creation. Add to that the object saving when the script ends.
> * The autonumeric ID from the DB, only saving the object as soon as it
> is created. Main drawbacks: extra save for the object (it will be
> modified and saved later in almost every case), the object maybe ends
> up being temporary (that shouldn't happen, you don't need a persistent
> object for that, but who knows)
>
> I would like to get comments on these methods, which of them you think
> is best, and also if you can come up with any other (hopefully better)
> methods.
>
> Thanks in advance.

I would try a combination of 1 and 3. A unique string id has the
advantage of being unique universally, which makes your object less
tied to the database. I have ran into situations where data has to be
exported/imported between different instances of the application, where
a auto-increment key was inadequate.

Here's a possible scheme:

* Call uniqid() once in the script, then generate subsequent ids by
appending an incrementing number.

* An id of an object would have two parts: the unique string and the
database key. When created, the object acquires only the unique string.


* Obtain the database key only if the object is saved. Save the
database key to a hash table so that objects holding ids with just the
unique string can obtain it.

* When saving an object that links to another, check the database key
part of the id. If it's null, then save the linked-to object first and
obtain the datakey key from the aforementioned hash table.

[Back to original message]