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 <ch...@global-village.net> 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 (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/chill%40global-village.net >>> >>> This email sent to ch...@global-village.net >> >> -- >> 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 (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org >> >> This email sent to m...@wardle.org >> > _______________________________________________ > 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/mschrag%40pobox.com > > This email sent to msch...@pobox.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