Re: Just one more anecdote

dawn wrote:

<big snip>

>>
>> This weakened assertion, that the data model "could be a factor" suffers
>> from the same problem as the original stronger statement, it is floating
>> free of any context or perspective.

I've snipped everything above this and will be snipping everything below this that centers on your pre-conceived ideas about this project. We've established well that you believe that the data model had something to do with the failure, and the reason you believe that is just because you do.

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

>

>> But you cannot list the project in question because there is no evidence
>> the data model had anything to do with it.

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

<big snip>

>
> I shouldn't. I do agree that the RM does do a lot of this well. I
> will also fully support the RM approach of putting a mathematical model
> behind the discipline. I have no problem whatsoever using relations to
> model propositions, logic to do queries, etc. It is a combination of
> some of the implementation details in SQL-DBMS's plus the statements
> that we can't think of data in any other way that are problems for me.
> It is sometimes very helpful to have a tree or di-graph API, for
> example. I'm ready for SQL to be retired, but I would not want the RM
> retired, simply exhanced.

I am beginning to form the opinion that you are confounding SQL products and the tools used to manipulate data. I myself had a hard time with the conceptual change from monolithic LAN development with the likes of Foxpro to C/S and 3-tier stuff, and I wonder if you aren't having the same trouble.

I say this because everything you mention above, and the ordered lists you mention below (which I've snipped for brevity) can all be done very easily in tables in any available SQL product. However, the great flexibility needed to present the tables to users is till pretty much a roll-your-own affair for every shop out there, no matter what the toolmakers would have us believe. And so it may be that a Pick tool has some handy widget for presenting X-ref lists, and you have found you have to do more work with dev tools that hit database products. And you probably do, because the makers of those tools are obsessed with object-orientation and don't know jack about databases (oops, did I just say that? how harsh of me).

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, the model can do anything, but the tools for outside the db server have not caught up.

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

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.

Again you are asking for a toolset. 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 own choice when confronting these realities was that SQL products (not the pure RM, which is not available to me) were so strong and solid in what they do that I would be happy to build my own libraries to deal with them because I really believe we'll be storing facts in tables for centuries.

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

<snip>

>> >
>> >> is an epicycle in the Solar System,
>> >> meaning it is a complication introduced to try to fix a basic
>> >> misunderstanding of how things are put together.
>> >
>> > Recognize that I'm talking about the logical model not about how things
>> > are put together.  What is the API?  Can we talk about a human being as
>> > a whole or must we partition it into smaller components?
>> >
>> >> A direct consequence of Downs' Law is that the best way to design a
>> >> system is to go directly to table design.
>> >
>> > Again, I wish I had your clarity on that one.

?

>

>> I've certainly tried to share it with you :)   For instance, I explained
>> it
>> above and you yawned.  If you can't get past the yawn, you'll never
>> appreciate the RM.

I strongly believe your issues are with the tools that sit on top of commercial SQL products. I had to give up lots of GUI goodies when I left foxpro, but in exchange I got a real db server. This is worth the price of building some of my own libraries, especially when I reflect on how many people are *still* building libraries for Foxpro.

<more stuff about pre-conceived ideas snipped>

>

>> Now I ask with all respect, why is it that you are so fascinated by the
>> RM that you keep coming back?

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?

>

>> Are you like the atheist that never stops
>> talking about religion, hiding a desire behind a criticism?

Well one day I'm going to have to come to your office and show you Andromeda, I think it is what you want :)

> I know it can be better than LAMP (for example).

Yes, LAMP is not much of a light. FOr me it is LAPP, using Postgres instead of mySQL, because I can create databases that completely implement all business rules.

> I have some hints and
> no proof, that the data model makes a difference and that applications
> written using the RM to date (all SQL-based) have caused the cost of
> ownership to rise, not fall.

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?

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, is robbing all of us of any insight you can offer on the other elements. It is perfectly on-topic to discuss the interactions of databases with other layers, so please tell us more about that, perhaps we can all gain.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)