|
|
Posted by Erwin Moller on 11/19/84 11:46
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.
Hi,
IMHO your third solution is very good, mainly because you make sure that
every object has a DB-related unique identifier, which you relate to the
(serialized?) object you store in it.
Your second solution (the ID-manager) could actually rely on this if you
choose to implement it that way.
[Postgresql]
One sidenote: If you use Postgresql you could decide to use the
serial-function to retrieve a new ID WITHOUT actually storing it right
away.
(Maybe other DB's have this option too, I am not sure, but ever since I
learned PostgreSQL my interest for other DB's faided away. ;-)
Something like this:
supose you have a table like this:
CREATE TABLE tblobjects(
objectid SERIAL PRIMARY KEY,
serobject text
)
Now you can get the next serial/autonumber like this:
$SQL = "SELECT nextval('public.tblobject_objectid_seq'::text) as
mynextobjectid;";
// execute it
The serialname will differ of course, so look it up.
In that way you get the next ID with minimal CPU-cycles.
Use the required ID later to insert.
In Postgresql you CAN insert your id in a serialfield (as long as it doesn't
exists of course).
Also note that everytime you call nextval(someserial) the number will be
increased by 1, so you are safe to use it later like this:
$SQL = "INSERT INTO tblobjects (objectid,serobject) VALUES
($yournewidhere,$yourserobjecthere)";
Just my 2 cent.
Good luck.
Your project sounds like fun. :-)
Regards,
Erwin Moller
Navigation:
[Reply to this message]
|