Re: foundations of relational theory?

Marshall Spight wrote:

>"Tony Gravagno" <g6q3x9lu53001_at_sneakemail.com.invalid> wrote in message news:dvh0pvo70vrue56jma8gkjotmnu9gm8vtu_at_4ax.com...
>
>
>>This must sound horrifying to you relational guys, but again, we don't
>>view the system primarily as a database with applications supporting
>>it. We view the application as a having the database as one of its
>>components - unless the application needs a reference in the
>>dictionary it doesn't get one.
>>
>>
>
>Hypothesis: PICK systems work well for application development
>because of excellent application development tools and tight
>integration between the application language and the DBMS.
>Agility is enhanced by the fact that some of the more complex
>possibilities for data models, such as many-to-many relationships,
>are simply excluded. In contrast, SQL DBMSs, while having a superior
>theoretical basis and a data model that can handle arbitrarily complex
>relationships, are hampered by having no standardized application
>builders or tools. In addition, SQL is particularly hampered
>by the fact that its core data structure, the multiset, has no
>corresponding entity in popular programming languages, causing
>a huge conceptual gap, or "impedence mismatch" between DBMS
>and application languages.
>
>I'm not saying this is true or not, but it seems consistent with
>what I've read in this thread. Anyone care to critique?
>
>BTW, if my hypothesis holds, it suggests (to me, anyway)
>that the right way to respond is to try to understand the
>best of each; the benefits of RAD that come with good
>tools and integration in PICK land and the superior
>theoretic foundation that relational (the
>"inspiration for SQL" :-) has.
>
>Anyone care to critique?
>

Hey, I think you have hit the point. I can understand, that those who are used
to building applications (like the PICK folks) within one conceptual environment
would feel that going to SQL + [your favoring programming language] would be a step backwards because of mismatch. And they would be right, in a sense.

And it is in that light that I see the complaits of SQL (and by implication of relational).

This is also the reason for interest in OODB's: the desire to stay in the same environment.

The other way to approch the mismatch problem is to extend the relational environment
towards the app side. However, it looks like computer scientists look at the world
from either a db-perspective or a programming perspective and these views don't
seem to combine. Why this is, is a mystery to me. Just to quote Jayadev Misra in
http://www.cs.utexas.edu/users/misra/Speeches.dir/Schlumberger.Jan02.pdf:

"In this context, let me suggest a problem worthy of your attention. The fundamental
structuring principle for systems is hierarchical organization. It permeates the world around us; social and political systems are hierarchical. We have found from experience that tree-structured file systems, hierarchical organization
of large domains such as the internet, and system designs in which each component
itself is regarded as a system, is convenient. Even within object-oriented programming, the notions of components and encapsulation impose hierarchical structures.

Is it time to consider a more democratic structuring principle, similar to what
they have in relational databases? I am driven to these considerations by the need
to view a system from different angles. I can look at this building floor by floor,
or by its electrical, plumbing and computational infrastructures, or by the people
who work here by their professions. I would like to slice the same system in a
variety of ways depending on which aspect of it I want to study. I would like
to see my file system not only as being hierarchical but also providing groupings
according to other criteria: all files that constitute the chapters of a book ought to
be arranged in a sequence so that I can read from Chapter 3 to 7, say. I would
like to see the list of all printers in the campus, even when the campus network is
organized by departments. How do we support multiple views of a system while retaining the advantages of hierarchical structuring? How do we exploit multiple
views during program design and evolution?"

Now (as pointed out previously in this newsgroup by Paul Vernon) why does he say "...what *they* have in relational databases"? Does he not consider db-science as part of computer science?

And secondly, he is in search of something "similar to what they have...". Why
do we have to reinvent the wheel? Why not use something that's there?

Of course the same applies the other way a round: why don't db-scientists try
to think of how they could better help in application building. They are, after all
the raison d'être of databases (well, at least 99% of databases). Why is there
this gap?

best regards,
Lauri Pietarinen Received on Sun Oct 26 2003 - 07:11:55 CST