Re: EOModeler Again...
Re: EOModeler Again...
- Subject: Re: EOModeler Again...
- From: Chuck Hill <email@hidden>
- Date: Wed, 07 Jan 2004 21:13:47 -0800
James,
I think you are missing the point of EOF (objects) and focusing too much on
the low level implementation details (SQL). However, I'm not sure if I can
explain this for you. You ask if what you are describing makes sense. In
EOF terms, no. Five project attributes are not a project any more than two
wheels, a spark plug, and a seat belt are a car. You might be able to fool
EOF for a while but I would expect trouble.
I wouldn't worry about the extra data being pulled back for 10
rows/objects. It will be cached and reused. If it does turn out to be a
bottle neck, you can start using raw row fetches to pull back the key and
what attributes you want and promote this to a full eo later if you need.
Finally, 200 columns? Wow. Wow. That is a lot for one table. With
accessors/mutators that gives a minimum of 400 methods for the Project
class and you've not even started to add functionality. Personally, I'd
take a long, hard, close look at this and see how some of this can be
broken out into other tables. I'd think this would be worth it just for
abstraction and organization's sake.
Chuck
At 03:33 PM 07/01/2004 -0600, james cicenia wrote:
>Chuck -
>
>Thank you very much for your reply. It seems others have a similar
>confusion.
>
>please see my response....
>
>> James,
>>
>> You seem to be confusing Entities and fetch specs with tables and
>> views.
>
>not really... though they are somewhat similar to me I admit.
>
>> While you can link multiple entities to the same table for performance
>> reasons I'd try to avoid it as it can lead to problems. If you find
>> out
>> that you need to do something like this for performance reasons (and
>> I'd
>> only do so after evidence that performance was a problem) then "raw
>> row"
>> fetches are a more appropriate solution.
>>
>> In your case I'd model two entities, Portfolio and Project. I'm not
>> clear
>> on what you intend by "portal", perhaps that is another entity.
>
>Portfolio to project is a one to many relationship. I will be using the
>following
>patter a lot. I wish to display in a quadrant (portal) on my web page a
>"canned"
>query result in this case of projects. The Project table/entity is very
>large with
>about 200 attributes/columns. The quadrant will only wish to display the
>top 10 projects (based upon the "canned" query) and only about 5
>attributes/columns of the selection.
>
>So I thought that I could make all those "canned" queries "prefetches"
>inside
>of their respective EOM entity. This entity would not be "the" main
>Project entity but in fact an additional entity that models a subset of
>the Project table columns
>
>Would this make sense?
>
>.
>>
>> You will have much more success with WO if you stop thinking about
>> tables
>> and fields and just think about objects. Chances are there will be no
>> performance problems and you are worrying needlessly. You might also
>> want
>> to reconsider the design of the project table. Is it fully normalized?
>
>My tables are well normalized and all my relationship between tables
>accurate
>and accounted for.
>
>>
>
>
--
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.