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: Pierre Frisch <email@hidden>
- Date: Wed, 21 Jan 2004 10:27:17 -0800
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.