Re: Mixing OO and DB
Date: Sun, 2 Mar 2008 08:33:27 -0800 (PST)
On 2 Mar, 15:45, Patrick May <p..._at_spe.com> wrote:
> frebe <freb..._at_gmail.com> writes:
> >> >> You've asked this before and it has been fully answered.
> >> >> The two components change at different rates for different
> >> >> reasons, especially in distributed applications and when the
> >> >> database supports multiple applications.
> >> > The only answer so far is about "denormailzation for perforance",
> >> > which is a very debatable argument.
> >> It's not debatable at all.
> > Ok, show me an example of such schema change that wouldn't affect
> > the application code.
> Denormalization for performance is just such a schema change.
> The data supported by the schema doesn't change, only the format. If
> you have SQL littering your application code, all of that has to be
> changed and retested. If you have an O-R mapping layer, for example,
> only the mapping code needs to change.
Still no example. I was asking for the schema before and after such change. Then we could evaluate if the application code would have to change too, or not.
> >> In addition, when a database supports multiple applications, the
> >> schema may need to change for one application but the others should
> >> be insulated from that change. This is common in many enterprises.
> > Addning columns or tables wouldn't affect the other (old)
> > applications. If you have other changes in mind, please show an
> > example.
> Changes to the schema to support new regulatory requirements are
> not uncommon. Sometimes these are simple additions, but they can also
> involve splitting or, less commonly, merging existing columns.
> Changing ordinality is another not infrequent change; an existing
> application can continue to function by using the primary or highest
> priority element on the many side of the relationship but a new
> application or component can take advantage of the full set.
Please give one example (schema before and after).
> During development, many shops are using iterative methods that
> require changes to both the schema and the application. When there is
> more than one project ongoing at the same time, insulating the
> application from the schema allows the new changes to be incorporated
> when it makes sense for the application team, rather than requiring
> all teams to change in lock step (a sure recipe for schedule slip).
This is all very nice words, but at least we need some examples to verify it.
> >> > Yes it is indeed bad design to force every SQL statement to be
> >> > wrapped inside a method.
> >> So you prefer littering your code with embedded SQL?
> > I wouldn't write exactly the same SQL statement in many different
> > places, in that case I would use a function. But I would wrap every
> > SQL statement in a function.
> Did you mean to say that you _wouldn't_ wrap every SQL statement
> in a function? If so, you wouldn't pass a code review in my teams.
Happily I don't belong to your team....
When someone fail to support his methods about software development, he can always claim his methods has lower maintenance costs, since it is almost impossible to verify such argument.
> >> This isn't even an issue for the systems I work on.
> > Why not?
> I've recently been working on low latency systems in the
> financial services industry. We have to keep the database, and any
> other disk based storage, completely out of the critical path of the
> business transaction or we won't meet our performance requirements.
What kind of "business transactions"?
//frebe Received on Sun Mar 02 2008 - 17:33:27 CET