Re: Just one more anecdote

Kenneth Downs wrote:
> dawn wrote:

<snip>
> This leaves me with only one thought, and that is about hunches. I learn by
> both deduction and intuition, and have had many wonderful ideas I could not
> explain that turned out to be right. However, no matter how often I've
> done it, the next time I present an idea to decision makers they seem to
> think they are entitled to a reasoned step-by-step explanation.

Even I require such reasoning before accepting either my own or another's hunches as if they were fact.

> This has
> been very good for me because it forces me to fill in the blanks instead of
> just shouting Eureka! And once in awhile it has even saved me from some
> blunders as I worked through an inspiration and found some fatal flaws.
>
> So, if your hunch is valid (because as you say later you are probably older
> than me and Mother Knows Best), then you ought to be able to think it
> through and give real concrete details that we can all look up and verify
> in some way, or at least debate.

That isn't how brains work, IIRC. Hunches come from other areas of the brain than language. They also might be based on many things that the person with the hunch cannot decipher. At the point where I can take all of my hunches in this area and turn them into clear reasoning expressed in language, then I'll be on Celko's doorstep for tips on how to write and publish ;-) I'm using this forum to try to get from intuition to logical explanation on this topic OR, and this would also be ok with me, to shake my intuitions on this topic as faulty.

> If you can't then Ken the Judge is going
> to summarily rule for RM, the defendant, based on the fact that the
> plaintiff has completely failed to make even the beginnings of a case and
> has already tried the patience of the court.

understood!

> >
> >> But you cannot list the project in question because there is no evidence
> >> the data model had anything to do with it.
> >
> > I know of no projects where there is any documented evidence of a data
> > model being a significant component in either the success or failure of
> > the project. I can imagine a project where this is the case, however.
> > If you have an idea of how to collect emperical data on this (for no to
> > low dollars), please let me know.
>
> I can't resist a parting shot:
>
> Ouch, you know of none? Then the idea exists entirely in your own mind?
> Do you read G.K. Chesterton? I would say you sound like one of the madmen
> he describes in the beginning of "Orthodoxy".

as logical an explanation as any ;-)

<snip>
> For what it's worth, that is what I am working on right now, this week.
> Right now my own system builds a hyperlink on the screen for all child
> tables of a table, allowing the user a drill-down. This however is only
> the most basic way to use a foreign key. With only a single flag you can
> do a lot, such as specifying in the fk definition that the UI should list
> all matching rows in the child table, instead of just having a link to that
> table, or even more complex stuff showing different kinds of
> cross-references.
>
> You see, the problem is not in the model,

You are taking one model of the data and turning it into another. If the original data model can map to another, then I would like to be able to work with the best one, or one of my choice, rather than interfacing with the db products only by way of relations, for example.

> the model can do anything, but the
> tools for outside the db server have not caught up.

In part because they insist that the "data model" used to interface with the products be a relational model.
>
> <snip>
> > OK. So, if my requirements for a model are that there be no visible
> > ordering data that I need to see and/or manipulate programmatically
> > when working with ordered lists, then would the RM be the best model?
>
> I'm sorry Dawn but you are talking like an MBA again. What you are asking
> for is a high-level tool, which for a programmer is an API call and for a
> user is a screen, that allows things like push, pop, and insert without
> referencing anything but the list items in question.

When you work with a dbms, there are many behind the scenes features that the dbms takes care of. If relational theory is the best implementation technique (something I'm happy to let others decide) then please hide THAT from me too when there are better models for a person/developer to work with.

> In other words, you want a programmer to say "Insert new item X before Y" or
> "Move existing item Z to after H" without knowing anything about the table
> design. For the user this would naturally be some kind of drag-n-drop
> where they slide X up above Y and so forth.

I want the developer to say "here is a data model and it includes this list" and then when that list is either tossed to a UI or a DB, it "understands" how lists work with inserts and deletions, for example.

> Again you are asking for a toolset.

of course. I'm asking for a dbms that is not based on modeling data only as relations.

> The tables do this fine. You just need
> libraries to keep the user/programmer from worrying about it. If those
> libraries don't exist, then you are slowed down by the lack of those tools,
> and that would be a valid reason to reject the RM, simply because it is
> starving for companionship.

My understanding was that the data model was intended for modeling data used by software applications for delivery to people and processes as needed. If there is a better data model to use in a particular instance, then that is what I'd like to use. It doesn't mean that the RM is worthless, just that it is not the only mathematical theory, nor model of data that is useful in the development of database-driven software.

> <SNIP>
> >
> > In general, I would rather write and maintain set operations on
> > relations than looping and navigating til end of file, for example.
> >
>
> If we were in a buddhist retreat center, I'd suggest you medidate on that
> statement for a month.

I've been at it for longer than that oooooooommmmmmmmmmmmm

> <snip>
> > My tables are more like record sets, yours are more like row sets.
>
> ?
records can have embedded lists in them, for example, and have ordered attributes

<snip>
> The conflict is not about theory and reality though, it is about identifying
> what has caused you to blame the RM when in fact you can't produce anything
> at all no matter how pressed. Why not try to come up with some other
> ideas? I've presented the tools hypothesis, what is your hypothesis?

Some of the hypotheses I have had are:
1. "Relational databases" have been one cause of higher cost of ownership for database application software. 2. 1NF the way it is still taught in college does not arise from a proper theorectical understanding of a model of data based on relations. There is no foundational reason to model data without repeating groups (nor without lists, for that matter). 3. A 2VL is a better implementation for a data processing dbms, whether using the RM or not.
4. Modeling data as lists, trees, di-graphs, functions, and other collection types instead of only as relations can make for bigger-bang-for-the-buck software development. 5. We could have more maintainable and less expensive software development if constraint logic were applied using the same specification and engine for UI and DB (and web services and any other place where such logic needs to be applied).

and many more.

<snip>
> You have to widen your target. Why just attack the RM? I am dead serious
> here, why not attack web servers, HTML, web app languages like Perl and
> Java? Why not look at the big picture?

Not to worry, I'm much more a generalist than a specialist than it might seem, but I need to understand this area better and figure out where the problems lie, so I can fix 'em.

> Your hunch about newer projects is probably right. I'd bet money on it in
> fact, but your fixation on a single element, the RM,

it is my biggest mystery related to s/w development right now.

> is robbing all of us
> of any insight you can offer on the other elements.

good technique, Mr. Downs :-) As much as I hate to admit it, I am planning to start a column er, blog, this Fall because I do think I also have some information and insights of worth. But I'm using cdt to learn, not to teach.
cheers! --dawn Received on Thu Aug 04 2005 - 19:29:41 CEST