i'm an enum fan ... lookup tables are dead to me, because, as someone already
pointed out, you almost always want them synced between code and the database,
which invariably creates a mismatch at some point. the only reason i use lookup
tables at this point is if the enumerated values are runtime-mutable.
technically putting the enum name in a field isn't unnormalized, either, since
that IS the "primary key" for the enum. just because it happens to be a string
isn't a problem.
ms
On Apr 15, 2010, at 4:52 PM, Mark Wardle wrote:
> I've found this interesting.
>
> My problem is I already have >80 entities. For instance, I have an entity
> representing structured medical data: as such it has about fifty pick lists -
> representing these as separate entities will be a nightmare! Using enums
> seems to work well and keeps these items in a private namespace.
>
> I also find it very convenient to create a NSDictionary with keys and default
> values that can be used in awakeFromInsertion - Ive found it a bit clumsy to
> start doing fetches to set default values in awakeFromInsertion.
>
> Unless there's a WO-way of doing that.....
>
> The other issue is when calculating things.
>
> Using an enum, I can do:
>
> If (reflexPlantarRight == ReflexPlantar.EXTENSOR) { ....
>
> I've always found checking EO identity a bit clumsy!
>
> Mark
>
> --
> Dr. Mark Wardle
> Specialist registrar, Neurology
> (Sent from my mobile)
>
>
> On 15 Apr 2010, at 18:53, Chuck Hill <[email protected]> wrote:
>
>>
>> On Apr 15, 2010, at 5:53 AM, Ramsey Lee Gurley wrote:
>>
>>>
>>> On Apr 15, 2010, at 8:07 AM, David Avendasora wrote:
>>>
>>>>
>>>> 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..."
>>>
>>>
>>> Wait, what is the DBA doing with some dumb DB tools when he has D2JC? (^_~)
>>>
>>> I believe the enum prototype in wonder stores them as a string. So,
>>> continuing with Mark's example, your DBA would just see NORMAL, SIGNS_ONLY,
>>> MODERATE, etc. He doesn't see some fk and need to jump to another table to
>>> figure out what that fk happens to be. It sounds like you're arguing
>>> against enumeration entities now (^_^)
>>
>> But said DBA will then commence whining about non-normalized data.
>>
>>
>>>
>>>>
>>>> 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 ([email protected])
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>>>>
>>>>>>> This email sent to [email protected]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40mac.com
>>>>>>
>>>>>> This email sent to [email protected]
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>
>>> This email sent to [email protected]
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall
>> knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org
>>
>> This email sent to [email protected]
>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
