True Relational To Pseudo Relational Mapping

A software layer on top of a PseudoRelationalDatabase? (like all those based on SQL) that hides the SqlFlaws, and allows the user to interact with the database as if it were a TrueRelationalDatabase?. An example of this could be AlphoraDataphor.

On the other hand, since it doesn't follow all indications in the TheThirdManifesto, maybe AlphoraDataphor should be considered an AlmostTrueRelationalToPseudoRelationalMapping?.

Several questions come to my mind...

Putting a "true relational" front end in front of the industry standard SQL interface to "relational databases" strikes me as ironic, and inefficient -- because, as I understand it, the major relational database products work by converting SQL to an internal query language which is Truly Relational so that they can do real relational calculus on it. So it seems to me that the real solution to the problem would be to define a real relational language -- something to replace SQL. You'd have to do this anyway, to have a "True Relational" API to convert to the ANSI Standard PseudoRelational? SQL API that is the current standard. If you could define a good "True Relational" API, then all that would have to happen next is that the major database vendors (including Oracle) would have to support it. ...by doing a simple translation to their current internal "Truely Relational" representations. -- JeffGrigg

How do you know that the internal query language is Truly Relational (why should it? why it can not be as lacking as SQL? AFAIK it might be closer to the particular implementation details of the DB, but that doesn't mean it is closer to being Truly Relational, I agree with you that we need to use a real relational language, for example TutorialDee (like in RelProject). The book explaining how to build a Truly Relational has existed for quite some time ( look at TheThirdManifesto)...so... what is keeping everybody from abandoning SQL? IMO 3 things:

Therefore, I think the community needs to show the database vendors that it is interested in having a Truly relational query language, and that it is truly interested in having a higher level of compatibility between database vendors, and while we cannot directly mess with the code of Oracle or DbTwo and add native TutorialDee support in to them, we can create mappers (or perhaps I should call them drivers?) to wrap the access to the pseudo relational databases, making it possible to use a more robust and powerful language. I believe that after people start seeing the advantages of this new language, and start creating solutions using it, the WordOfMouth will finally reach the database vendors, and they will start to be interested in adding this new language natively in their databases (and perhaps start creating extensions as libraries and not as language modifications that can not be ported between databases?).

Why should I want Truly Relational Query Language and results? What benefits would it give me? ANSI SQL standards and related library APIs give me a high level of compatibility between database vendors, and they also enable useful performance and portability tradeoffs too. Please list some benefits that would inspire 'the community' to want Truly Relational over the kinds of things they have now.

For starters, lets remember SqlFlaws... then read TheThirdManifesto and TutorialDee...

[I wonder if the WikiPuppy responsible for the recent spawning of various *RelationalTo*Relational* pages would consider deleting the others and consolidating them into a single page, such as this one? That would foster and encourage discussion -- without the imposed structure, disappointing lack of content, and generally unwelcoming nature that an empty collection of topics inevitably creates. When the content grows, refactoring can be based on actual content rather than a predetermined structure. Keep in mind that DoTheSimplestThingThatCouldPossiblyWork and YouArentGoingToNeedIt apply to Wiki content as well as code.] -- DaveVoorhis

WikiPuppy: BarkBarkWoofWoof? (JustJoking?): I created it that way to mirror the way similar topics were discussed on ObjectRelationalMapping... I thought it would be more convenient that way..Of course, you can DisagreeByRefactoring? (and I'll take no offense, but please, if you do DisagreeByRefactoring?, not only refactor, but add your opinion) -- LuxSpes

In his defense, sometimes modularizing pages is the only way to remain sane. People passing by a huge mother sized page aren't going to read it. Keeping it simple sometimes means making short articles and pages, instead of long drawn out flamewars that span 30 pages on a single page. Whether that applies to this page and those other relational pages or not, I'm not sure. Some people on this wiki seem to be thinking in StandardPascal? and just like to throw more and more procedures and comments at the end of the program. Some of us think in Modula and like to create separate topics, even if they are related to other topics in some ways. Since the earth is one single place, why not have one single page for all topics, since earth ultimately relates to all and everything here on earth?

[I agree; I'm simply suggesting that the refactoring be done after there's content, not before.] -- DV

EditText of this page (last edited November 21, 2014) or FindPage with title or text search