Re: Expanding Import
Re: Expanding Import
- Subject: Re: Expanding Import
- From: Ken Anderson <email@hidden>
- Date: Wed, 08 Mar 2006 12:05:36 -0500
Just to throw my 2 cents in the ring...
I generally build my models with robustness in mind, but never model
relationships from reference data to transactional data. This is
where reflexive relationships get you intro trouble - where the
destination (the transactional data) can grow very large.
As far as XP goes and how that applies here, I think it depends on
your situation. If you do a lot of consulting where clients are
indecisive, and extra hours are argued, the XP approach to EOF is a
good one when there are only 1 or 2 people on the project. If you're
working on a large team, not so much, since it's more difficult to
add relationships on the fly when other people are using your
database, models, etc. If you're building something for use
yourself, and you have a much better idea of where you're heading, a
more non-XP approach is what I prefer.
Ken
On Mar 8, 2006, at 11:54 AM, Jerry W. Walker wrote:
Hi, Arturo,
On Mar 8, 2006, at 9:33 AM, Arturo Perez wrote:
Jerry W. Walker wrote:
Hi, Scott,
On Mar 7, 2006, at 8:16 PM, Scott Winn wrote:
Thanks much to everyone for the help. Let me know if anyone
hears a good rule of thumb for what does and does not need a
relationship.
In my experience, however, I've seen two approaches to all but
the primary rule of thumb above.
One says put all the relationships in your model as bi-
directional and prune them only if (and when) they cause
problems. This approach tends to make your initial coding easier
because you can simply assume, for any but a relationship to
reference data, that the relationship is bi-directional and use
it as such (in the WO way :-) ) without thinking about it a lot.
When you find a problem, as you have, determine the offending
relationship and prune it. This approach tends to be followed by
the "Make it work, make it right, make it fast" school of
developers.
The other (followed by strong XP advocates) says to only add
relationships, and only in the direction required, that are
needed to complete the immediate requirement. Never add anything
(relationship, attribute, method, class and so forth) for some
ill defined future need. In XP terms, only add what's needed to
implement the current story and nothing more.
Hi Jerry,
Nice precis and helpful information.
Thank you. I was kind of desperately hoping that it wouldn't start
a flame war between the two "schools". :-)
I'm not an advocate of XP and your example above shows one of the
reasons why. For me, the primary objective is to model the data
so that I understand what the customer is saying, what I need to
provide, and the best way to implement it. Following the XP
approach would lead to a rather ad hoc data model, IMHO.
I used to teach classes in software process and was a firm advocate
of the "model EVERYTHING" in the specifications (let alone the
Entity Relationship Diagram) before starting on the code. I was
much later involved in an Extreme Programming (XP) project, which I
considered to be glorified hackery at the time. I approached it
with as much fervor as I could muster, knowing that it was bound to
fail. When it failed, I wanted to be able to say, "We gave it our
best and it just doesn't work."
On the contrary, it worked far better than any process I had used
before. That project made me a sound advocate of XP, but with
caveats that I would be pleased to share with anyone who asks. One
of those caveats is to try to avoid being a purist. I tend to put
more into the EOModel than needed up front for the very reasons you
mention. There are XP purists who might argue, but it was difficult
enough just succeeding with pushing XP through as the company
process that I've never been overly worried about purism (in my own
estimation, others would argue :-) ).
Note that I am not saying put in all Entities you can imagine with
every conceivable relationship. My position is that you put in
all the Entities you know you need and all the relationships you
think you need as well.
I definitely agree with you on the Entities, I'm less strongly in
agreement on the relationships. I generally try to add all the
relationships I know I'll need, but otherwise stick to the XP
approach. On the other hand, for systems for which I'm comfortable
that they won't be pushed hard, I add nearly all bidirectional
relationships to keep it easy and then prune where problems occur.
If it seems to be a system for which efficiency might be a major
concern, then I tend to stick to unidirectional relationships,
particularly in the areas that Chuck mentioned.
But I probably am of the MIW-MIR-MIF school of thought. Any
suggestions on how to pronounce that :-) ? mew-mer-mif...
ROFL!! I didn't know how to pronounce it, but will probably use
your suggestion from now on. :-) Kind of follows Julius Caesar's
pattern: "Vini. Vidi. Vinci."
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
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