Pavel Cisar wrote:

> unordained napsal(a):
>
>>> The main problem with the relational model is that we're at the
>>> verge of handling complex models described by huge and complex
>>> semantic definitions and introduction of ontologies into standard
>>> data management that relational model (even if we would dump SQL
>>> with it's closed world assumption for good) can't handle
>>> sufficiently even with sophisticated semantic extensions.
>>>
>> It could be helpful for the discussion to show examples of such
>> situations -- what problems are hard to solve with the relational
>> model, what data hard to organize?
>>
> <SNIP>
> > The point is that if we're to judge models based on how well they
> > support our needs in the real world, rather than just academically (I
> > believe the relational model pretty well won that battle already),
> > we'll need examples.
>
> It all boils down to semantics. Relational calculus doesn't care about
> meaning, period. You can join apples to oranges as long as it happens
> that joining attributes are "compatible" (yeah, that ought to be solved
> to some degree by more ingenious type system, but not completely), but
> the main problem is that the result has no semantics attached and could
> be completely bogus and there is no way you can tell. Sure, most of it
> is in fact built in constraint of SQL (or any other relational query
> language), but it's that way because relational model is based on
> relational algebra, which is just that - an algebra, a computational
> tool. It's hard to impossible to carry semantics through relational
> computation. So all relational query languages basically gave up on this
> and left all responsibility to developers. And developers who live in
> world of CPU cycles, algorithms, registers, numbers, strings, objects
> and data structures generally sucks at seeing through information
> representation (data) to actual information.
>
>

Pavel, I have read your post over and over and still can't heads nor
tails of it.

When I referred to semantics, I was referring to the SQL language
semantics. SQL syntax has its good flaws and its bad flaws, but it
generally gets the job done. When you are talking about semantics, you
clearly have something else in mind.

What are the problems you see with relational semantics (it's been years
since I've heard someone hold forth on the relative merits of relational
calculus vs relation algebra, but we'll let that one pass)? What are
the data semantics (or lack thereof) that concern you? What concrete
problems do you have?

Among the problems I have with complex data relationships (persistent
objects, CODASYL sets, entity/attribute, hierarchical) is that the DML
is navigational, i.e. visiting a record and deciding where to go next.
Among the serious problems with navigational DMLs I have seen are:

* A change to the data structure usually invalidates working programs
* Record at a time interactions are catastrophically slow over
network boundaries
* Insufficient regularity for high level tools (dearth of 4GLs, etc.)

Relational languages address these problems nicely, and giving a set of
aggregating interfaces, can move things further along. So I don't
particularly want the database system to model complex relationships
other than primary/foreign keys and table inheritance. I'm sure other
people feel differently, and I look forward to an interesting debate on
the subject.

What I do want to do, however, is banish the idea of physical
datatypes. Tiny item, short int, int, long int, big int, etc. can be
handled with a single type "number" with a scale factor to handle
currency (pennies -- with the state of the dollar, who cares?).
Similarly, I want to fold char, varchar, and clob into single "text" (no
bound or size). I actually did this inside of Falcon, though there is
no hope of support from the MySQL server. If anyone wants to hear more,
let me know -- the basic idea came from this list a fair number of years
back.

So, Pavel, what is it that you want to do and can't?


--
James A. Starkey
President, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]