3 ms·

If you are looking to solve performance "with a relational model" then you do not understand physical independence and the relational model. This is exactly wha

If you are looking to solve performance "with a relational model" then you do not understand physical independence and the relational model. This is exactly what the article explains you should not do. You mean DBMSs, not databases. Yes, that's the argument, but it's precisely this kind of lack of understanding that prevents better RDBMSs.

catnaroek 10y ago
Exactly. The idea that you have to sacrifice the right abstraction for the sake of performance is preposterous, and can only be explained by lack of imagination. Just because most SQL DBMSes happen to implement relations, foreign keys, aggregates, etc. in a specific way, it doesn't automatically mean that the specifics of these implementations must be elevated to the status of laws of nature.
- srean 10y ago
  Indeed, but it helps a great deal to give examples that show better ways, or if not working examples, even sketches of credible implementation ideas.
- sgeneris 10y ago
  SQL DBMS are not relational, so they don't really implement relations (they support bags and NULLs), not all their operations preserve closure, have weak support of relational constraints, of physical and logical independence, I could go on and on. Problem is practitioners confuse RDBMSs with SQL DBMSs and are incapable of seeing what they're missing in terms of practical benefits of the latter.
  - dragonwriter 10y ago
    NULL is part of Codd's articulation of the relational model, even if later theorists have proposed cleaner variants of the model without it.
  - catnaroek 10y ago
    Yeah, these things you mention have always annoyed me. In particular, every relation should have a primary key, possibly consisting of zero attributes. If the primary key consists of zero attributes, the relation must have at most one element, because the primary key (the empty tuple!) determines every other attribute.

catnaroek 10y ago

Exactly. The idea that you have to sacrifice the right abstraction for the sake of performance is preposterous, and can only be explained by lack of imagination. Just because most SQL DBMSes happen to implement relations, foreign keys, aggregates, etc. in a specific way, it doesn't automatically mean that the specifics of these implementations must be elevated to the status of laws of nature.

srean 10y ago
Indeed, but it helps a great deal to give examples that show better ways, or if not working examples, even sketches of credible implementation ideas.
sgeneris 10y ago
SQL DBMS are not relational, so they don't really implement relations (they support bags and NULLs), not all their operations preserve closure, have weak support of relational constraints, of physical and logical independence, I could go on and on. Problem is practitioners confuse RDBMSs with SQL DBMSs and are incapable of seeing what they're missing in terms of practical benefits of the latter.
- dragonwriter 10y ago
  NULL is part of Codd's articulation of the relational model, even if later theorists have proposed cleaner variants of the model without it.
- catnaroek 10y ago
  Yeah, these things you mention have always annoyed me. In particular, every relation should have a primary key, possibly consisting of zero attributes. If the primary key consists of zero attributes, the relation must have at most one element, because the primary key (the empty tuple!) determines every other attribute.