This discussion started because we need to understand the definition of PseudoRelational (as opposed to TrueRelational) to be able to say if a TrueRelationalToPseudoRelationalImpedanceMismatch exists. 

For the moment:

''Assume we have implementations of the RelationalModel that are usually known as "true relational" systems.  Also, assume we have (primarily) SqlLanguage systems.  Now, assume we wish to integrate them.  That's what TrueRelationalToPseudoRelationalMapping is about.'' (More/less extracted from a comment of DaveVoorhis at the end of the page) 

In other words (for the moment):

*Rel (TutorialDee) = TrueRelational
*ANSI SQL = PseudoRelational (BagAtational?)

----

''Dammit, "wide" tables are still "relational". Normalization beyond value repetition is a subjective opinion. Nothing pisses me to full bounds than when zealots mistake personal preferences for universal truths. Damn them to Rev. Wright's basement! --top''

And who says they aren't?  I don't see anything it this page against "wide" tables...

''Where is "pseudo-relational" defined?''

[It isn't, but in context it clearly refers to systems inspired by the relational model that allow duplicate rows, and possibly those that allow NULL values.  I.e., SQL.]

''Relational, as originally defined, did not directly address the issue of nulls. If it was added later (by whatever "authority"), this suggests that it is a minor issue, and not a key. We need nulls (or blanks) anyhow at *some* stage because the user generally prefers a fuller table view, rather than strips of data.''

[The user never need see a "fuller table view, rather than strips of data" or vice versa.  The developer may or may not see "strips of data" depending on how the model is implemented.  Anyway, the issue of nulls has been contentious since the first practical implementations inspired by the RelationalModel.  It was not "added" by any authority, and was tackled by DrCodd in his later papers.  This is, however, off-topic for this page, and I'm sure we needn't re-hash a debate that has been going on for nearly thirty years.] -- DaveVoorhis

''The issue of the definition of "pseudo-relational" is still open. Without a definition, this topic is drifting. If that definition is not tied to nullness, as was originally replied, then what is it tied to?''

[Primarily, it is tied to the allowance of duplicate rows, as I mentioned.  However, true relational systems (i.e., those that do not permit duplicate rows, and typically don't allow nulls) tend to have certain characteristics -- such as the availability of flexible database constraint specifications (beyond the usual CHECK, FOREIGN KEY, and UNIQUE), use of relation-valued variables (RelVar''''''s) instead of tables, avoidance of column-order dependent syntax, availability of user-defined operators & types, and clear exposure of the RelationalAlgebra -- that make it a non-trivial task to integrate pseudo-relational with true relational systems.  Hence, this page.  If you're not comfortable with "pseudo-relational", think "SqlLanguage".] -- DaveVoorhis

Well, I agree that duplicate rows disqualify something. But, the rest are personal opinions (often from idealists, zealots, and agitators it seems). Column ordering is a shortcut for human convenience, such as positional parameters instead of named parameters (see UniversalStatement). I agree that named parameters are more flexible; however, they are also more verbose. Why should it be allowed for app statements but not query languages? This is becoming a WalledGarden for a certain flavor of relational promoted as the One True Religion. --top

[Whatever.  We could quibble for megabytes about each issue, but this isn't the page for it and I doubt it would accomplish anything, and the empirical benefits are largely unproven.  Proving (or disproving) them will keep me busy doing research and writing papers for the next decade.  For now, assume we have implementations of the RelationalModel (in particular, those whose flavour you've dubbed the "One True Religion") that are usually known as "true relational" systems.  Also, assume we have (primarily) SqlLanguage systems.  Now, assume we wish to integrate them.  That's what this page is about.  While it may be mainly a WalledGarden at the moment, as further development on this topic (and on related projects working in this area, like the RelProject and AlphoraDataphor) occurs, I'm sure it will be cross-linked as appropriate.] -- DaveVoorhis

----
MayZeroEight