Re: EO-Modeler Again
Re: EO-Modeler Again
- Subject: Re: EO-Modeler Again
- From: Arturo Pérez <email@hidden>
- Date: Fri, 9 Jan 2004 21:36:20 -0500
On Jan 9, 2004, at 12:50 PM, james cicenia wrote:
I have modeled correctly all my tables and relationships completely
normalized in EO-Modeler.
That may be. But a database-centric (albeit normalized perfectly)
perspective may not be the most effective for what you are trying to
achieve.
The question is ... should I create new objects in EO-Modeler that
only have a subset of those attributes of the main class...
If you believe that some subsets of your data are separable from
others then there is some kind of problem. When I've done this
sort of thing in the past I've been very careful to separate two
kinds of data:
1. Functional. This is the data required for the application to
function properly. For example, username/passwords, emails,
relationships
to role/permission structures, etc. Without these you do not have
an application. This functional data drives behavior.
2. Reporting data. User eye color, favorite foods, etc. This data
never
impacts application behavior. Usually it's included because the
marketing
department wanted it (or thought they did :-). 90% of the time the
application
never uses this data. Perhaps you're doing data warehousing or a content
management system or a simple reporting system with no authentication.
In this second case I've done what Mr (Sr?) Strausz suggested. A kind
of star schema
approach to the problem where related but not essential attributes are
kept.
You can propagate the primary key, etc. The benefits here are that the
entity
remains smaller, the database operations are a bit quicker. The
downside is
that the database starts to become difficult to use without something
like
WebObjects. But these are separate tables, not separate entity
definitions
on the same table.
The biggest (widest) table I ever used had 50-75 attributes. Of that,
only about
20 were ever really used for anything and about a dozen were "dead." I
don't believe
(as Chuck apparently does as well) that anything "conceptual" can have
that many
attributes.
But, again as Chuck said, you'll never make progress in using
WebObjects effectively
if you don't step away from the database-centric view of the problem
space.
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.
That's not a view. The question I would ask is: Do I have an
entity with 5 displayable attributes and some relationships or do
I have a single entity with 50 attributes. Given that I've yet to
see a useful entity with that many attributes I would say (to myself)
that I have an entity with 5 attributes. Back to correct the schema.
Should I create a new class with just those 5 attributes?
Only if you redesign the database to fully support this new class.
So that when I fetch those rows I only bring back the 5 attributes
vs. the 50?
Well, if you don't need the fifty attributes why do you have them?
Here's
the beauty of the EOF faulting mechanism. Pull those out into a
separate
dependent object (as they say in J2EE land) and fault them in when you
need
them.
Then I could add those fetch specifications to that
class.
I think that's an EOModeler confusion. The fetch specs live with an
class inside EOModeler because a fetch spec returns only that type of
class.
Other than that the concept of adding a fetch spec to a class doesn't
make
a lot of sense.
Would this be better? More efficient? easier to code the
application on this foundation?
It's impossible to know what better would be without knowing what you're
trying to achieve. Given that we don't have NDAs with you it would be
unwise for you to share that with us.
I can't see it being more efficient. It would certainly be less
productive
as now you have twice as many things to keep track of in a situation
where
the database would be of minimal help.
Easier to code probably not. If a class doesn't have a lot of business
logic
then one would usually leave it as an EOGenericRecord. In which case
it doesn't
matter (from the coding perspective) if it has one or a million
attributes.
Hope this helps.
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
_______________________________________________
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.