Re: encoding entity info in primary keys
Re: encoding entity info in primary keys
- Subject: Re: encoding entity info in primary keys
- From: Pierre Frisch <email@hidden>
- Date: Thu, 6 Nov 2003 17:04:03 -0800
The advantage of encoding the entity name in the primary key is to be
able to optimize the toOne relatiionship easily using the
EOModelGroup.Delegate.subEntityForEntity. I don't like compound primary
key as they are inefficient so I actually compound the name in the key
in my code.
Pierre
On Thursday, November 6, 2003, at 04:08 PM, George Domurot wrote:
We include the entity name in every object, but not directly with its
primary key. The primary key is a standard integer. We found that you
don't always need the compound primary key, but many times it does
come in handy (very handy actually) for object/code reuse. How many
times does anyone want to code the use of an Address object? I'm sure
everyone on the list has setup address fields too many times to count.
1 time seems most appropriate for the OO approach.
-Geroge
On Nov 5, 2003, at 6:40 PM, Pierre Frisch wrote:
We are doing exactly this in a very large project. Having the entity
name in the primary key has enabled us to optimize the model. We took
a very straight approach and generated our own unique ID (24 bytes)
and then create our own primary key by encoding this key as a String
and adding the full EntityName at the end and prefixing it with the
offset to find the entity name (just a precaution for the future).
This means that our primary key are stored as String and are quite
long but this is avery mild inconvenience. Strings are a lot easier
to handle if you need to write sql and for the length disk space is
cheap.
Just as a summary our primary key structure is:
2 char offset + 24 char unique id + entity name
Quite convenient and if your dba does not complain works very well.
If you would like the code send me a private email.
Pierre
On Wednesday, November 5, 2003, at 03:26 PM, Robert A. Decker wrote:
So, is anyone actually encoding entity info in their primary keys?
I've
done it in one of my projects and found that it allowed me to create
much
better designed models. Specifically, the ability to have a
relationship
to a superclass type rather that to each of its subclass types saved
me on
a number of occasions (for example, being able to tie your
relationship
to a Person type, but in your persons array having an array of both
Customer and StaffMember types).
The reason I ask is that the demo project seems to have languished. I
ended up trashing a bunch of the demo code since I couldn't get it to
work properly, plus I didn't like where they kept the identifier for
the
entity types (in the UserInfo dict in the model). However, I _know_
the
system I implemented won't be as efficient since I'm not grabbing
bits
directly from the Numbers - instead I'm converting to Strings, then
taking
the first three letters and then converting that to a Number, which
gives
me my entity identifier (I know, lame lame lame).
I'm thinking of taking a very big project and adding encoding of
entity
info to primary keys. However, it has to be very efficient. Talking
to
other developers over the years it seems that no one takes advantage
of
this capability, and so I'm wondering if there are specific reasons,
or if
it's just because, well, the demo sucked. :-)
thanks,
Robert A. Decker
http://www.robdecker.com/
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.