On Apr 14, 2010, at 9:49 PM, Ramsey Lee Gurley wrote:

> 
> Well, there's only going to be one of each enum in memory.  So, that's a 
> bonus.

Memory is cheap. :-)

>  They are fast to access... I don't block a thread waiting on a fault.  
> That's good too. On that same line of thought, there's no need to prefetch 
> them.  

Well, reading in 5 key-value rows from a table can't take all that long, even 
if you don't prefetch them. Obviously if they are used thousands of times in a 
transaction, then you'll need to speed it up, but I'd optimize it only if it's 
actually slowing things down.

> Does any of that make a big difference? I don't know.  Can't hurt though (^_^)

Depends on your definition of pain., I guess. :-)

I've always looked at it as a case of if the value is defined only in code, how 
do people who are reading the data directly out of the DB know what the value 
in the DB means? How do you make everything consistent between your app and a 
reporting system reading data out of it?

DBA: "Oh hey, this transaction has a status of 1. What does 1 mean? Is it 
Active? Is it Closed? What? Now I've got to track down that bleeping developer 
and ask him to interpret this data. Would it have been so hard for him to just 
include all the context of his application in the DB where anyone can get at 
it? It's not like a few 5-row key-value tables are going to bring the DB to 
it's knees..."

At least that's what I hear in my head whenever I think about it.

cue: Chuck.

Dave


>> 
>> On Apr 8, 2010, at 4:52 AM, Mark Wardle wrote:
>> 
>>> Hi all, please forgive a very simple question but I'd like to create a
>>> lightweight (non-EO) to-one relationship from an EO. I make heavy use
>>> of D2W so I want to fulfil the WO/EOF rules and use to-one
>>> relationship components....
>>> 
>>> I usually create a new entity and have a genuine heavyweight EOF
>>> relationship but I have several properties for which this seems
>>> excessive.
>>> 
>>> I have an entity (FormEdssFull) which can have a visual field score
>>> for both right and left eye.
>>> 
>>> Can I do this with a java enum?
>>> 
>>> public enum VisualAcuity {
>>> NORMAL(0, "Normal"),
>>> SIGNS_ONLY(1, "Signs only:"),
>>> MODERATE(2, "Moderate"),
>>> MARKED(3, "Marked");
>>> 
>>> /* insert enum constructor etc... */
>>> }
>>> 
>>> and then create the appropriate accessor and mutator in the entity?
>>> 
>>> What do other people do in these situations?
>>> 
>>> Many thanks,
>>> 
>>> Mark
>>> 
>>> -- 
>>> Dr. Mark Wardle
>>> Specialist registrar, Neurology
>>> Cardiff, UK
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>> 
>>> This email sent to webobje...@avendasora.com
>>> 
>>> 
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40mac.com
>> 
>> This email sent to rgur...@mac.com
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to