Re: Mixing OO and DB
Date: Thu, 06 Mar 2008 22:51:31 -0500
Message-ID: <m2tzjjfayk.fsf_at_spe.com>
frebe <frebe73_at_gmail.com> writes:
> On 4 Mar, 22:52, Patrick May <p..._at_spe.com> wrote:
>> Decoupling the SQL statements related to the now denormalized
>> schema from the application code that invokes them has significant
>> value. The change can be made and tested in isolation and the
>> application itself doesn't have to change at all. When the new
>> version of the component containing the SQL code is deployed, the
>> application simply runs faster.
>
> If you create a new table, no existing SQL statements has to change.
As I explained, this isn't about adding a new table. It is about encapsulating the information received from the database in such a way that the implementation of how that information is retrieved can be changed without impact to the components that use it.
>> > One could also argue whether your denormalization would gain any
>> > performance at all. Why don't you publish the schema, indexes,
>> > query and let the guys from c.d.t, evaluate the possible
>> > performance gain.
>>
>> Because that has nothing to do with the core issue we're
>> discussing.
>
> It was you who introduced "denormalization for performance" as an
> example for supporting your claims. If it has nothing to do with the
> core issue, you should have used another example.
You asked for an example of the database schema changing for different reasons than the application logic. Denormalization for performance is such an example that does occur in real enterprise systems.
>> Decoupling components that change for different reasons and at
>> different rates is simply good practice, whether those components
>> are business services, database schemas, network protocols, GUIs,
>> or anything else. Coupling components that change at different
>> rates and for different reasons imposes maintenance costs and makes
>> systems more difficult to enhance.
>
> First, one have to show that they do change for different reasons.
I have provided several examples in this and other threads. You should stop asking as if I have not.
>> Your requests for specific schema examples are a red herring
>> that would take this conversation down a rathole of different
>> design alternatives.
>
> It would make us able to validate your claims.
No, it would not. It would quickly devolve into a discussion of particular optimization choices and a long thread about different possibilities. My point is that these kinds of changes do occur in real enterprise systems. I and many others have direct experience of this. If you do not then we work in very different environments.
>> > Still no schema examples....
>>
>> Still waving that red herring around. Have you or haven't you
>> ever experienced these kinds of changes?
>
> The questing is if the scenario above the case only the schema to
> change and not the application ("change for different reasons").
> Without knowing the details of your example, it still looks obvious
> that both the schema and application need to change. That makes your
> example useless in this discussion.
You're completely ignoring my explanation. Here is one particular example, again:
Consider a regulatory change like Sarbanes-Oxley. Companies need
to add additional monitoring rules, but they have existing
applications in place that they don't want to change any more
than absolutely necessary due to the high cost of doing so. The
applications can be encapsulated to work without change within a
different workflow. That workflow requires additional
information in the database, in particular more detailed audit
information and finer grained tracking of individual steps in the
process. This results in schema changes but does not change the
behavior of existing applications.
Existing systems have no reason to change. The database schema must change to support new functionality and new uses of existing functionality. In other words, application logic and the database schema change for different reasons and at different rates. Issues like this arise frequently in enterprise environments.
> Since our discussion is about schema that changes, but applications
> which doesn't. Some details about those schema changes would be
> interesting.
I have provided several examples of the types of changes that occur in real enterprise systems, at a sufficient level of detail for those people who have experienced them to recognize the situation and for those who have not to at least understand it. Detailed schemas for particular occurrences would be a distraction at best.
>> >> Either you've experienced this or you haven't.
>>
>> > The question if your method is a good one or not, not if the
>> > scenario is experienced or not.
>>
>> No, the question is whether or not you've experienced the
>> kinds of problems that tight coupling of logically disparate
>> components can cause.
>
> Since we don't agree whether the components are logically disparate
> or not, we have to start with that issue.
Evidently you haven't experienced this situation. That's fine, but it doesn't mean that others have not. I've provided sufficient information for you to understand the basic issues.
>> The difficulties that arise are very real. The decoupling
>> techniques weren't created just for the sake of coding.
>
> The reason OO people like to "decouple" the SQL statements is:
> 1. OO languages doesn't have good support for embedding SQL.
> 2. OO like to model data as a network graph, in opposite to the
> relational model.
(1) is not accurate. It's as easy to embed SQL in languages like C++ and Java as it is in C. Are you thinking of a different language?
OO techniques model behavior rather than state. The network graph is for invoking behavior, not for accessing state. This is another reason for decoupling the database schema from the application logic -- when OO techniques are used the models of the two components are very different.
>> >> If you haven't, you should at least be able to understand that
>> >> these kinds of environments do exist and these kinds of changes
>> >> do take place. This is not a discussion about particular schema
>> >> changes, it is about the value of decoupling.
>>
>> > It is a discussion about whether wrapping SQL statements will
>> > help handling schema changes or not. Without knowing what kind of
>> > schema changes we are talking about, any evaluation of your
>> > method will be impossible.
>>
>> Not so. Application logic and database schemas change at
>> different rates and for different reasons.
>
> This doesn't become true, just because your repeat it ten times
> every post. Try to spend your time with supporting the claim,
> instead of repeating it.
It doesn't become less true just because you've either never experienced it or you refuse to read and understand the examples I've provided. My claim is well supported, both in this thread in real enterprise development environments.
>> >> They've personally experienced the costs of doing so and don't
>> >> want to go through it again.
>>
>> > Mainstream OOPLs has very poor support for embedding SQL, that's
>> > why the cost migh be high. Older non-OO languages has much better
>> > support for embedding SQL.
>>
>> So basically you're just suggesting that OO techniques should
>> never be used?
>
> No, you have to write SQL statements as string in your host
> language, if your host language lack support for true embedded SQL.
The mechanics of accessing SQL aren't a significant problem in practice. I've used the pre-processors from Oracle and other RDBMS vendors. They don't provide a significant improvement in development time.
Even with those tools, decoupling the application logic from the SQL interface, and therefore the database schema, is good practice.
>> "Excellent performance" is domain dependent. Is this system
>> primarily CRUD or is there some complex business logic involved?
>
> If you have a definition of "CRUD" and "complex business logic", I
> would be able to answer the question. For example, producing an
> invoice can be pretty easy with a good database design. With a bad
> database design it (the business logic) quickly becomes rather
> complex.
That sounds like a CRUD component -- essentially you're creating a report. The complexity of business logic is certainly a continuum. Something like a simple data aggregation would be at the non-complex end while, to pick an example from a recent system, calculating the value at risk for a portfolio of a few hundred thousand positions (with minimum latency and dynamic scalability) would be more complex.
Sincerely,
Patrick
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Fri Mar 07 2008 - 04:51:31 CET