Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Phlip wrote:

>
> Team A, however, can sack its DBA any time they feel like, and can easily
> replace the DB-facing modules with some other system.
>
> Team B's DBA is the lord of all he surveys. He or she has perfect job
> security, and a lot of clout in the team's decisions.
>
> So what's the /real/ motivation for this thread, guys? ;-)
>
> --
> Phlip
> http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

Many DBAs are nothing more than glorified system administrators who are more concerned with backing up the data and allocating space when necessary. I'm not a DBA, but I sure do have a deep appreciation for a clear and concise explanation of data that a data model gives.

But what does this have to do with anything? The question you pose seems to have more to do with organizational issues and the human condition. Indeed, the question seems to reflect more of organizational problem, and even perhaps a struggle for power and control. It is ironic that such an argument should revolve around who has control of data, rather than code, given our forum and the seeming need to trivialize a systematic and computable expression and enforcement of rules as data (i.e. the data model). It also seems like a total deflection from the more substantiative arguments in this thread.

For me, it would be about the countless hours of trying to rationalize meaningless data and "reverse engineer" a data model reflecting and representing a business universe of discourse because of quality, or lack of it. Business rules that are enforced by one part of an application but not by other parts of some "framework" make the data meaningless. It might be "agile" in some loose, generalized interpretation, but it lacks credibility and consistency, if that can even be defined without a data model.

It doesn't matter whether the database or "persistence engine" could be swapped out, because garbage with one "persistence engine" is still garbage in another. And data structures that are now termed agile having nomenclature such as SOME_OBJ(attr1, attr2, attr3, att4, att5, att6, att7.......) is utterly meaningless to me. In 100% of the cases where even asking the developer who had created such structures, not a one could accurately and concisely give an accountability of what was held in it, what it represented, or what rules were supposed to enforced in a declarative manner.

How does one formulate questions, much less get answers, from such a state of affairs?

In the end, the business must expend tremendous resources trying to redefine and express rules for data, try to "clean" the data", and then sometime down the road, throw out the application code anyway in favor of the next big thing. Rarely does the business ever take the course of trying to "clean" the code.

In contrast, in cases where where there was a data model that expressed structure, manipulation, and integrity; and there was a data manager for systematically enforcing the rules and semantics inherent in the allowable data states and state transitions, regardless or what or how many applications, application paradigms, frameworks, and bucket o' bit pseudo-database application code developer wanna-be's there were, the conversion from one database manager to another was trivial in comparison to the reverse-engineering decoding exercise that is now often the only alternative.

• Dan