The TrueRelationalToPseudoRelationalImpedanceMismatch is a label that could be used for the set of problems that could be encountered when using a PseudoRelationalDatabase? (BagAtational?), as the mechanism for storing the data for a TrueRelationalToPseudoRelationalMapper.
Does it really exist? Does it.. for example, force you to allow nulls in your otherwise perfectly complaint TrueRelationalToPseudoRelationalMapper? or those are just problems with particular implementations ?
Some of the possible mismatches could be:
- True Relational to PseudoRelational? costs time and money
- True Relational to PseudoRelational? forces you to add SurrogateKeys? to eliminate duplicates (or to add a column with a "count" of the duplicates)
- The root cause of the impedance mismatch... some think it is trivial to solve, others, that it is not. See BagNeedScenarios for a discussion.
- True Relational to PseudoRelational? forces you to use nulls
- True Relational to PseudoRelational? needs triggers for constraints
- is not possible to define constraints using Bag Algebra? or is it just not efficient?
- True Relational to PseudoRelational? needs support of user defined types in the PseudoRelational? database
- how to translate them if there there is no support in the PseudoRelational? database?
- True Relational Operation/Constraint to Pseudo Relational PersistentStorageModule?/Trigger
- What features are required in PersistentStoredModules so that the a D language (such as TutorialDee) can be compiled in to PersistentStoredModules? (Compilation is necessary so that the underlying PseudoRelationalDatabase? protects its own integrity even if not accessed using the TrueRelationalMapper?. One example would be the very powerful constraints available in TutorialDee, and the fact that there is not even one Sql database that implements CREATE ASSERTION, so the D constraints would have to be compiled into triggers/materialized views with checks)
- True Relational to PseudoRelational? needs Relvars
- most (all?) PseudoRelational? database have no support for relvars, it is going to be too hard implement them in an efficient way
Are this real problems/mismatches? or perhaps TrueRelationalToPseudoRelationalImpedanceMismatchDoesNotExist
? and one can perfectly wrap PseudoRelationalDatabase
? under a TrueRelationalMapper
?? or perhaps that wrapping is only possible as long as the PseudoRelationalDatabase
? has
TuringComplete PersistentStoredModules?
Discussion on what is PseudoRelational? (and its differences with TrueRelational?) moved to PseudoRelationalDefinitionDiscussion
See also BagSetImpedanceMismatch
True Relational To Pseudo Relational Impedance Mismatch