Re: database systems and organizational intelligence

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c97u5m$quc$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:%MItc.4483$G61.3076_at_newssvr32.news.prodigy.com...
> I see constraints as parameters to a constraint engine that has services
> that do what would be needed -- pass back what would be needed for a GUI,
> validation after receiving data or before storing it. Parameters are
> typically "declarative" or fill-in-the-blank-data, but the engine itself
> could be anything, I would think.

Yes, exactly. I think it's a true RDBMS, but it doesn't matter. Dataphor, for example, seems to run as either an in-process client-side engine, or as a true server. Unless you're dealing with a Web app (where everything comes from the server), it's critical that the client-side constraint engine be a projection of the server-side - or at least that the two are generated from the same source, or dynamic, or whatever.

I think we're on the same page here, and I think that a properly-implemented RDBMS, AND an environment that takes advantage of it for application development, would please you. Forget the "R" and even the "DBMS" if you like, and just think of it as a constraint engine.

> > I like Tutorial D, although it's a bit wordy.
>
> It makes a good tutorial for relational thinking, but it definitely
doesn't
> roll off my fingertips -- it's just too, too, what's the word? I know --
> relational ;-).

Yeah, it's a bad name. D4 from Alphora isn't bad... but until I write ERK, I'll just never be satisfied, I guess.

> I've used XP in industry and didn't even think of bringing it into a
> classroom -- good tip!

It works well, even in little 2-hour "brown bags" to a small audience.

> It seems to that Java could be more useful for reusability, thus pushing
it
> further up the food chain, than it has been to date.

Yes, you're quite right. Java can be done in very good style, but is too often written like a bad translation from COBOL or VB.

> There are some impressive libraries available that help with that.

True, but so many of the libraries are awkward. Reflection, for example, is so awkward that someone had to invent aspect-oriented programming to deal with it (yes, that's a gross oversimplification). Compare with Lisp/Scheme, which essentially give you seamless ability to drop in new code, and to manage it like your existing code - as data in lists. Not saying this is good for everything, but the language itself allows you to define your own language, and program in it. Most OO languages get in the way of that (Smalltalk doesn't, I think) - an inherent limit on abstraction, which after all was one of the goals of OO.

> Of all of the languages in the mix, the "relational one" (SQL) is one of
the
> most problematic, causing us to treat stored data differently than other
> data, for one thing

I agree with you here, but probably not for reasons you'd like. I wish programming languages were "more relational", as opposed to making the data "more graph-like" like XML and OO.

> (and then tied to that bloomin' 1NF for another).

Well, as Date says, 1NF is something of a matter of perspective, as long as the structures don't intrude on the core relational algebra/calculus. If you've got a list type in there, and have defined operators, have at it... and in addition, handling such user-defined types nicely in reports and a UI are matters of projecting user-defined types elegantly into the front end, something that a good relational-based development environment should do. I think Dataphor does that... have to evaluate to see.

> > Hopefully soon we will have 2 sets of declarations: data (in all its
> glory,
> > with full constraints that express the meaning), and components (how
> > processing components relate - navigation and delegation). Much of the
> guts
> > of the components should be generated by the basic data constraints.
> That's
> > my hope for the future... and no, I don't mean just one choice, but
> > certainly fewer choices, constrained by education in basic logic and
> minimal
> > thinking (stating what you want and letting the implementation engines
> > enforce it and generate code).
>
> I'm interested in similar goals, but I think the declarative language for
> the DBMS being so disjoint from application logic has been significant
cost
> to our industry,

Agreed!

> and my take is to move things out of the DBMS to be
> accessible to the whole system, while others are working to build more
into
> the DBMS (especially those who make money selling proprietary DBMS's).

Well, "out of" and "into" aren't precise enough. I'd like them to be defined in one place, and think a constraint engine is a good place. I also think the constraint engine should be an RDBMS - no conflict with its responsibilities as a constraint engine. Keep in mind that a constraint engine has to keep many users happy, and synchronizing factual statements various users are making (i.e. writing data, asserting facts, etc.) is a key job. And that fits nicely with what a DBMS does - though today, SQL DBMSs do it badly.

> Maybe if we had a common xml schema for specifying data constraints, along
> with common services for applying such, ...

The common schema can be a relational engine. I think you'll find it much harder using a tree structure, since rules don't tend to respect hierarchies very well (you can writes rules about hierarchies, but that doesn't mean the rules themselves are easily expressed hierarchically!). I'd be interested to hear more about the common services for applying them... what do you mean?

> I just haven't seen the fruit from that relational seed

None of us have, although I'd still be interested to hear more from those who dealt with old network databases as SQL was coming to the forefront... SQL was embraced as solving problems, but did it? Did it solve some and introduce new ones?

> and now that it is almost dead, I think I'll skip it ;-)
> [yes -- just pokin'] Cheers! --dawn

Well, unfortunately (for you) I don't think it's dead yet, and have great hopes for its revival.

• erk