Re: Mixing OO and DB

topmind wrote:

> Patrick May wrote:
> 

> 
> Often the original "source" tables are not changed, but rather a data
> warehouse tuned for a particular department is created or changed. But
> even if such is done, the total effort for wrapped versus non-wrapped
> SQL is not going to be significantly different. Remember, I am not
> against wrapping if there is duplication of usage. It is the one-off
> or short few-off ones that are not worth it in my opinion.
> 
> The Clutter Tax of wrapping is there for almost every maintenance
> transaction, but schema overhauls are comparatively rare.  Thus, even
> if wrapping did save say a day every 5 years, it will cost roughly a
> month of added effort due to the Clutter Tax. The economics simply do
> NOT support it. It hurts/slows *frequent* changes.

I once worked on a project where the UI code had quite a bit of embedded SQL and the batch processes used C++ O/R mapping. The batch and UI teams were similar in size with about 10 programmers each.

When it came time to add support for a second dialect of SQL, one of the batch programmers went off for 10 working days making changes at some low level in the mapping library. Some people made a big deal that the change happened without inconveniencing any of the other programmers and only took a single person two weeks to complete.

By contrast, the UI programmers divided up the source code into the areas each knew best and made whatever changes were necessary. It took a single day.

One might look at 1 person for 10 days versus 10 people for 1 day and conclude each cost about the same except for two factors: one big and one small.

The small factor was labour rate. Programmers come with differing skills, experience and salary. The UI team paid the mixed rate or average rate for all of its team members. The batch team paid at or near the top rate for its one team member.

The big factor was the cost of the mapping library. As it happened, the mapping library used by the batch team was all that was salvaged from a previous, failed attempt at the same project. From one perspective, the failed project was a sunk cost and the batch team got the mapping library for free. From another perspective, the company paid tens of millions of dollars to develop the mapping library, which was a major contributor to the original failure.

>>>>>>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).
>>
>> Again, why? Have you never experienced these kinds of changes?
>>They happen often enough in my, and others, experience that the
>>decoupling provided by OO techniques has proven useful. Despite what
>>some relational proponents think, developers don't come up with these
>>approaches because they dislike or don't understand relational
>>databases. They do it because they're trying to solve real problems.
>>
>> 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.

Why would it affect applications? We are talking about creating audit trails, which is old news in data management. DBMSes have been doing that for decades. Why does anyone think we have triggered procedures in the first place?

Unless, of course, we are talking about the idiots who decided DBMSes are "too slow" and re-invented their own "object database" or "persistence layer". In those cases, one would expect them to have a hell of a lot of work to do.

[snip] Received on Tue Mar 04 2008 - 00:29:35 CET