Re: Query result times in WO and mysql
Re: Query result times in WO and mysql
- Subject: Re: Query result times in WO and mysql
- From: Chuck Hill <email@hidden>
- Date: Wed, 21 Jan 2004 11:49:08 -0800
And if you are going to put it in the database, then in EOModeler mark the
Entity as "Cache in memory". This will result in all the objects being
fetched in a batch at first access. Subsequent access, even by fetching,
will be resolved by the datastore without a trip to the database.
Caveat: OK, I've not looked at this since 4.x, but this is what happened
back then.
Chuck
At 10:27 AM 21/01/2004 -0800, Pierre Frisch wrote:
>Actually there is a third solution. Have a Java object that represent
>the state that is not an EO but a pure Java Object. Map the attribute
>from a String into your Java Object Attribute. Create a static
>enumeration i.e. a list in the code for each state. You can make the
>objects immutable and create an instantiation mechanism that always
>return the same object for the same state. This would be a a full
>Object implementation without the DB penalty. Lookup table in the DB
>are nice but are usually costly in term of performances. Implementing
>your lookup table in Java and storing the resulting String in the DB
>achieve the same result at a much lower cost. The only drawback is if
>you need the lookup table for a non java base application.
>
>Pierre
>--
>Pierre Frisch
>sPearWay Ltd.
>sPearCat Web Catalogs, the flexibility of custom design, the price of a
>package.
>http://www.spearcat.com/
>
>
>On Jan 21, 2004, at 7:51, arturo wrote:
>
>> ----- Original Message -----
>> From: "Kent Harris" <email@hidden>
>>> I was going to place
>>> the names of US States in an enumeration entity but Lon's paragraph
>>> below got me to thinking that might be a mistake.
>>
>> Wearing my O/R purist tin-foil hat :-)
>>
>> There's a tension here between normalization, O/R modelling and
>> non-tool (or
>> non-WO) access to the database.
>>
>> Many forms of normalizations will suggest that state names should be
>> in an
>> enumeration table.
>> O/R modelling suggests that states may or may not be an entity
>> depending on
>> what else you need to do.
>> Non-tool access (e.g. sqlplus, isql, pgsql and reporting) wants
>> everything
>> denormalized so that the SQL requires fewer joins, is easier to read
>> and
>> write.
>>
>> For normalization the reasoning is that there's often more than one
>> attribute to a state: abbreviation & name. So, in order to avoid
>> redundancy in the table for names they get turned into an enumeration.
>> Also
>> to avoid having to have the names in more than one piece of code:
>> reporting
>> code, UI code, etc. Everyone uses the same table and values. It's a
>> data-driven approach.
>>
>> WO (and O/R) only cares if there's added functionality in those state
>> objects. For example, zip code validation (is this zip in this
>> state). If
>> there's no behavior then it's a "dependent object" and everyone loses
>> interest :-) In WO caching addresses most of the performance concerns
>> with
>> doing enumeration tables.
>>
>> The third point is, I think obvious.
>>
>> If you don't make them an enumeration then you should go to the
>> trouble of
>> creating a good validation system for them. After all, you don't want
>> it to
>> be possible to have someone enter the state "Kennessee" or "OW."
>> _______________________________________________
>> 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.
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
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.