There are a few reasons I can think of to put lookup tables in the database:
1) Can edit the user-viewable text without recompiling (if you design your
lookup tables correctly)
2) Localization
but most importantly:
3) Sorting happens at the database
sacha
On Apr 15, 2010, at 2:00 PM, Mike Schrag wrote:
> 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/sacha%40global-village.net
>
> This email sent to [email protected]
--
Sacha Michel Mallais 400 kg chimp
Global Village Consulting Inc. http://www.global-village.net/
PGP Key ID: 7D757B65 AIM: smallais
"Choke on that, causality!" -- the Professor, "Futurama"
_______________________________________________
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]
