Re: database systems and organizational intelligence

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c9fatk$psi$1_at_news.netins.net...
> "Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message
> news:4%Duc.30789$n_6.10190_at_attbi_s53...
> > [snipped]
> > What bothers me, though, is the language. There are many languages and
> > IT structures (databases included) that seem to be disassociated from
many
> > solutions.
>
> Precisely! There seems to be some notion among many database specialists
> that the data is independent from the use of the data (e.g. applications).

Applications depend on data, but why the reverse? It adds complexity, unless you know of some design method that allows the bidirectional dependence without effectively locking out later applications, and becoming the Big Ball Of Mud anti-pattern.

> There is some "data in a vacuum" work that is being done in the interest
of
> "ensuring" that the data can be used by multiple applications. Holding a
> discussion about the meaning of various relations, attributes, types,
values
> (and we can pick any of these to model a noun) in some general way without
> concerning ourselves with what we need to do with that data, is quite
> unnecessary, expensive, and causes unecessary expenses for the life of the
> system.

That's just wrong, or at least sounds mistaken and has no evidence behind it. Meaing is important, isn't it - if not, then why your need to consider what the data means to applications (and vice versa)? Types are all about "what to do with" the data, as are relations. I agree that domain-specific languages are extremely useful (and alleviate some complexity at the cost of adding some of a different kind), but to imply that there are no "general" statements you can make about languages or data is simply silly.

> In theory (not mine), this makes the data more immune from the need
> to change it when a new application needs it and over time. But that
isn't
> what happens!

But it can, and should. I've seen it happen.

> The data being detached from the purpose of the data is
> impossible and expensive to attempt.

The relational model is all about purpose, and flexibility.

> > When we're trying to develop a simple A/P check-writing
> > subsystem, we seem to constantly encounter digressions: data typing, 1NF
> > restrictions within the data, array conversions, variable scoping,
memory
> > access, and on and on.
> >
> > A database is such a natural part of a business application it's hard
when
> > the dbms is so distracting.
>
> Another good point. If the DBMS were to have a personality, most of them
> these days could be seen as bullies and not good team players with the
rest
> of the solution. Perhaps it doesn't view itself as an equal partner in
> providing a business solution, but as an entity all by itself that
> applications can choose to use or not. I would like to see
databases/DBMS's
> be more team players with the business and all other software that is
> working to provide business solutions.

Agreed - the DBMS should add value, not complexity and work. The app should be able to derive from it information that helps it work with the data.

• erk