Re: database systems and organizational intelligence

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:4%Duc.30789$n_6.10190_at_attbi_s53...
> Comments embedded.
>
> "Laconic2" <laconic2_at_comcast.net> wrote in message
>
> > > Doesn't this imply the intelligence lies within the developer/solution
> > > provider? If they know the purpose (the what and how) of the task,
they
> > > pick the language that minimizes the distraction from the task; for
> > language
> > > is nothing more than a tool.
> >
> > Very interesting.
> >
> > I think of the specification of the task as the WHAT, and the
> implementation
> > as the HOW. I'm not sure where purpose fits in, although it clearly
> does.
>
> Yes. The purpose is very important...very similar to goals, but broader
in
> nature. It's the WHY we're doing the WHAT and HOW we're doing it. :-)
>
> I think when we understand the WHY we can direct the WHAT and HOW. I
guess
> if my job doesn't require it, to know the WHY, I do what I'm told. I
think
> we'd agree the more we know the closer to the WHY we get and the better
the
> design and implementation will be. We're more experienced and
knowledgable.
>
> > It seems to me that "writing an A/P check" is a different task from
> > "developing as system that writes A/P checks".
>
> I agree, at the task level. The actual creation of the check (either
> physically or in the database) is just one of many tasks within a
> check-writing subsystem.
>
> If we understand WHY we would want to create an A/P check and WHY it
relates
> to the accounting and financial reporting as a whole we're much more
likely
> to efficiently develop this individual task and small subsystem.
>
> [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). 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. 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! The data being detached from the purpose of the data is impossible and expensive to attempt.

> 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.

> Obviously, the less distraction there is with
> language and dbms tools the more likely it will be we can directly apply
> business knowledge to applications. I think this would create more stable
> and longer lived applications.

Good points! --dawn

<snip> Received on Mon May 31 2004 - 15:10:57 CEST