|
|
Posted by nacho222@gmail.com on 11/19/61 11:46
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.
Navigation:
[Reply to this message]
|