Re: EO-Modeler Again
Re: EO-Modeler Again
- Subject: Re: EO-Modeler Again
- From: Chuck Hill <email@hidden>
- Date: Fri, 09 Jan 2004 17:07:48 -0800
- Organization: Global Village Consulting, Inc.
Hi James,
james cicenia wrote:
I have not been clear obviously.
No, you've been clear. I just think you're wrong. :-) While 200
columns (or even 50!) may be OK from a normalization point of view
that does not make it good design. Normalization is proscriptive of
bad design, but not prescriptive of good design. Two hundred
attributes is too much to hold in mind at once and hence too many for
practical use in a object/table. Surely some of these attributes form
related subsets: this set always occurs together, these are optional
unless this is given etc. etc.
You have correctly identified that you have a problem, but you are
trying to solve the symptom (slow performance due to excessive SQL
transfer of data) rather than the root problem (poorly abstracted
design). You'll find if you go back to object (not table!) design and
work out a set of human manageable abstractions that describe your
project data that the concerns below will vanish.
I have modeled correctly all my tables and relationships completely
normalized in EO-Modeler.
Bear in mind that this is an Object-Relational mapper not and
Entity-Relationship thing. It is object centric. It defines how your
*objects* are stored in some persistence mechanism. It is not
required to be an SQL database. If you persist in thinking of tables
and selects and views instead of inter-related objects you will not
derive the benefits of WebObjects. You will waste your time and
become frustrated. If all you want to do is select some columns from
some rows and dump them out in pretty HTML you might be better off
using PHP or perl (shudder).
The question is ... should I create new objects in EO-Modeler that
only have a subset of those attributes of the main class...
No.
Table1 --> 50 columns
ClassTable1 -> 50 attributes
HOWEVER,
I need to show.. in many places of my application Table1
but showing only 5 columns. In other words, a small view
on the number of rows.
Then do so.
Should I create a new class with just those 5 attributes?
No.
So that when I fetch those rows I only bring back the 5 attributes
vs. the 50?
No.
Then I could add those fetch specifications to that class.
Fetch specs do not belong to a class. They are used to retrieve a
sub-set of the objects of a particular class. You can model them in
EOModeler, write them in code in your eo class, or ever write them in
code in your page. Where they originate from is only relevant to the
ease of maintenance of your code.
Would this be better? More efficient?
If you only want to display a portion of an objects data and only need
the raw data and not any behavior, then doing a "raw row" fetch is the
WO appropriate way. If you also fetch the "primary key" this can
later be promoted to the real object when you need something more. See:
http://developer.apple.com/documentation/WebObjects/Reference/API/com/webobjects/eocontrol/EOFetchSpecification.html#setFetchesRawRows(boolean)
and methods in
http://developer.apple.com/documentation/WebObjects/Reference/API/com/webobjects/eoaccess/EOUtilities.html
easier to code the application on this foundation?
Definitely not. You will run into update inconsistencies with EOF.
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
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.