Re: database systems and organizational intelligence

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c98fu9$4mj$1_at_news.netins.net...
> I thought the aspect programming (of which I have only a tiny bit of
> knowledge) arose from C# and/or other MS .NET tools handling something
> better than Java, but that'll have to sit on my someday/maybe pile until
it
> bubbles to the top.

Not exactly - I believe it arose primarily around Java itself (and its many flaws). I could be wrong, though - I just haven't seen discussions of C#/.NET in connection with the origins of AOP, at least in Kiczales's early papers.

> > > 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.
>
> the data IS more graph-like -- I just want to view it as it is ;-)
> [over-simplification]

Well, then I envy you. If you've only ever had the need to view data as a single graph, then your requirements have been much kinder to you than mine have to me. Typically I see the need for many different graphs in different contexts, which is difficult to support through graph-like transforms, but easy when based on relations.

> > > (and then tied to that bloomin' 1NF for another).
> >
> > Well, as Date says, 1NF is something of a matter of perspective,
>
> as well as the premise for all of relational theory, being that all
> normalization requires 1NF to start with

So take it in its generous form, and use it as you wish. As you said, you still get value from 2NF and 3NF, right, even in Pick? Date's point is simply that the DBMS sees a single value at any given tuple/attribute "point". That single value can be "complex", but that's a type you've defined, and the DBMS doesn't care about that - you have to do the work. No special treatment for types.

> > 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.
>
> Agreed, except that I'd be fine with spec'ing them in XML and then leaving
> them in this tree structure for use - no need to do that XML to SQL/RDBMS
> mapping at all.

Well, if you can use constraints specified in XML format, you're a better human than me. I've yet to see a simple logic or data structure that XML can't render so opaque as to be unusable. Even the cleanest XML is dirty.

> Additionally, because I want more constraints to be
> specified by the users and/or end-users AND IGNORED by the database
(that's
> what gets put in the app code today, right?), I see the DBMS constrains as
a
> projection of the application constraints.

But certainly there are some things you actually want the users not to override, right? In any event, you argue for a domain-specific language interpreted in your app - a good thing. But you have to keep in mind that just because users can specify some things doesn't mean they'll be good at it, and your app has to have enough structure to not fall apart when they screw up.

> We can let a user say they want
> to enter and view address lines as max of 30 characters without the DBMS
> nosing in on that and fixing that length in the schema, for example. Sure
> there is a risk, but it is a risk worth taking when there is no fixed
> reason -- just the whim of the current user -- for sticking to 30
> characters.

I agree. I'd say there needs to be more analysis, though, to avoid things like a user who changes this and subsequently screws up the formatting of various reports going to other departments.

> We don't want users knocking down supporting walls without
> involving IT professionals, but we have got to let them hang pictures and
do
> other makeovers of their applications without requiring an extreme
makeover
> (using doctors).

Yes, true. This can be a slippery slope, but I think this sort of necessity argues for better typing, not less typing.

> Relational theory says it is about how to view the data, not how it is
> stored. In that case, the users know how they want to view it and the
> constraints should originate from there.

Well, if by users you mean all of them, then yes. VPs, CEOs, accountants, auditors, etc. are all users, to some extent. You have to take the body of requirements into account, not just Joe at the data-entry desk.

> I want to design constraints from front to back and not the other way
around.

Why? They come from both directions. It depends on which interested parties ("users" is too specific) you mean. The government has requirements, too...

> Some can stay at the front as
> "local constraints" (aka application software). Relational theorists seem
> to have "centralized control" as the key concept. I think I'm a more
> progressive parent than that. Sure there are risks, but it seemed to have
> worked with my kids. Users can take responsibility too and recognize the
> implications of changing the max size of a field by one character, for
> example, or even switching from storing only numbers as a product ID to
> permitting alpha-numeric.

Overconstraint is a problem too, as you indicate. No need to specify numbers only for an ID that the users determine, typically. And even if it is system-generated (and thus probably numeric), that's no reason to store it only as digits.

> > 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!).
>
> Rules can be built by specifying one function to apply after another --
> ands, ors, comparison operators, booleans, etc. A fork-in-the-road
function
> might lead to function A or function B as the next function -- rules are
> simply trees, even if a simple list tree, right? [I'll admit I didn't
think
> that through completely]

A given rule might be seen as a tree, but the set of rules for a business is much more complex than that. And in any event, you're talking purely about flow of decisions, not about the data to which those decisions are applied. That forms an overlapping structure. And given the complexity of the functions that can be specified, I'd doubt that a simple tree is better than a full language of some sort. Yes, parsing is more difficult, but it only has to be written once.

> > I'd be interested to
> > hear more about the common services for applying them... what do you
mean?
>
> One thought on it -- With the distribution of processes across machines
and
> across the network, there are times when you really need to use a
> synchronous service (or "subroutine", for example), but more often times
> when an asynch service would be fine (the software analogy to voice mail
> being highly underused in software applications). I'd like to see a GUI
> with a message window that doesn't keep interrupting the user like dialog
> boxes do (hate those things!) but provides information, warning, and error
> messages.
>
> So, for example, if some aspect of the UI cannot be set up to ensure that
> the user can only pick a valid option (by providing a list, for example),
> but must be validated after the user enters data, then after the user
> addresses that field, but before an entire document is submitted and
without
> tying up the user, the GUI could be a client of a constraint engine
service
> to validate that field. After that service is completed, any messages
from
> the validation could go into the message window, along with messages from
> other asynch services. The user might then find that they entered an
> invalid value somewhere before they submit the page.

Absolutely - and if they change the value to a "good" one prior to the first validation being done, the user should never see a message.

> When they submit a page, the process will know whether it has all data
back
> from the validation services and, if so, will know whether the data has
been
> validated or not.

Absolutely. This is where declarative constraints become absolutely essential - the engine should be able to do all of the above, with little work from the developer other than stating the required constraint, and perhaps a little about how the result is to be reported.

> > > 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.
>
> only if it is greatly fixed, and my take is that the starting point for
> fixing it is not the current RDBMS implementations.

Agreed!

> As disturbing as almost
> the entire IT industry seems to think XML to be from a theory perspective,
> it aligns much better with the way that users think of their data (primary
> due to its lack of 1NF and variable length strings that might or might not
> have tight constraints).

Any SQL DBMS worth its salt can handle variable-length strings, but I still disagree about the XML. I have yet to see a case where XML didn't completely annoy both end user and developers. It's used because it's widely-discussed; that's all. Software developers, for some reason still unknown to me, jumped onto the text markup bandwagon and sold the farm to do so. It's biting the asses' asses as we speak - hopefully it will be recognized as the snake it is, rather than just pushing those with I.T. budgets to further offshore, because gawrsh, this I.T. stuff is just too darned expensive (just like education - it is expensive, but consider the price of the alternative).

• erk