Re: getting the results of a sub select
Re: getting the results of a sub select
- Subject: Re: getting the results of a sub select
- From: Arturo Pérez <email@hidden>
- Date: Tue, 15 Mar 2005 22:02:43 -0500
OK. Let's take this from the top. But before we do, a quick question.
If the view you describe meets all your needs why do you have two
tables? Why not keep all the data in one table?
Now, the point of EOF.
If you're looking to sling lots of raw data around the EOF is not a
good match. It imposes a certain amount of overhead necessary for its
true objective (which we'll get to in a minute). From that point of
view, EOF is nice only in that it provides a mechanism for neophyte SQL
developers to leverage the abilities of more senior staff. I'm not
getting the impression that you're a neophyte at SQL. Experienced SQL
developers have more trouble understanding EOF than anyone else.
EOF's true objective is to re-map a normalized database back into
business entities. As you know, a normalized database is darn near
impossible for anyone to understand. There's a little data here, a
little there and the normalization prevents one from seeing the forest
for the trees (and branches and leaves :-). In this respect, its
objective is similar to EJB. But EJB is crap so let's not go there.
So, given a normalized database how does one recover the business
entities? By mapping all the tables necessary for a business entity
back into an EOF Entity. The mechanism for putting the Humpty Dumpty
business entity back together are the relationships.
So you want to use the relationships. You use them to reconstruct a
business entity. Having recovered the business entity you can then
leverage the semantics of the situation. One can talk about having a
Job entity. And one can talk about what Job entities can do. And one
can talk about what Job entities know.
From what little I've seen of your schema I'm guessing that a Job
entity has a requesting client and a Client entity has multiple jobs.
And Client entities have names.
HTH
-arturo
On Mar 15, 2005, at 9:00 PM, Theodore Petrosky wrote:
But it sounds to me that I would be better off
creating a view in the database and just creating a
link to the view. The view would include the
subselect.
CREATE VIEW myview AS
SELECT ji.jobnumber, (SELECT ci.cname FROM
clientinfo ci WHERE (ji.acode = ci.acode)) FROM
jobinfo ji;
now I can avoid totally the whole relationship
thing....
I feel that I want to push the backend to do some of
the work. Please correct me if this is the wrong
approach. I am more that egar to learn this new (to me
new) method. I am having a few problems with some of
the concepts.
Ted
--- Arturo Perez <email@hidden> wrote:
Ken Anderson wrote:
Ted,
You need to think of jobs and clients as objects
that have
relationships to each other. If you continue to
think about things in
terms of SQL and specialized queries, you're going
to have a hard time
with EOF (the database layer of WebObjects).
This can not be emphasized enough. If you can stop
thinking about the
SQL and just concentrate on what you need to do you
will avoid a lot of
frustration. EOModeler can be very helpful in this
respect. For a
neophyte WO person just let EOF do what it wants.
When it can't do
something or you're tempted to change how EOF has
defined something come
check with this list first. Otherwise you'll be
in for a world of hurt.
One thing that's important to realize here is
that, by default, EOF
will make a trip to the database for each client
you need to fetch. If
you're displaying client.cname in a table or
something, that can become
very inefficient.
Just to clarify this section as it sounds as if EOF
will fetch each
attribute of an object one at a time. EOF will
fetch the entire object
and all its attributes. However, for relationships,
EOF will place a
fault in the object as a stand-in to avoid joins &
the possibility of
loading hundreds of objects when you only need one.
__________________________________
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden