On Fri, 12 Oct 2018 14:31:10 +0200, R Smith <ryansmit...@gmail.com> wrote: > > >> An SQL database is deemed "Relational" when it can communicate mildly > >> relational data using mildly relational (but mathematically sound) > >> methods. It doesn't need to be (nor claim to be) the Almighty keeper of > >> all relationality, nor even simply conform to various specific > >> interpretations of the word "Relation".
>> There is no such thing as relational data, data is what it is and the 8>< -------- > I will call it relational data when it is structured to contain records > that stand in relation to other records. Relational databases, and the Relational Model, are not so called because their records stand in relation to other records. The Model, and the subsequent databases, are about relations, which are a long-standing and precisely defined mathematical concept. So, I'm afraid, you are actually wrong (in common with many others of course). 8>< -------- > its use/function/storage arrangement. Use and function can be put together, but not storage management with them. You can have any type of storage management you can think of as long as it allows the use and function and is efficient enough. This is one of the points of the Relational Model which almost all SQL-based databases ignore, they only have one or two storage arrangements, so "relational" products get blamed for bad performance when it is the design and implementation of the storage management that causes the problem, not the relational theory that is claimed to be behind the product. > Actually, never-mind, I'll concede the point. It's just data. *shrug* 8>< -------- > Your basic thesis here revolves around "SQL engines do not follow the > letter and the law of the Relational model" - and the reply, same is > before, is "We know. So what?". > (I'm not disagreeing, I'm just not convinced of controversy) "So what" is that they and their users do not reap the benefits of the model. Also they may produce incorrect results and we can not prove that they don't. Any data retrieval that was not anticipated when the system was designed may perform very badly or even be impossible. > Let me qualify that: Sure you can kick a person who feels controversial > out from behind any Bush, but if such a controversionist had a real > point, then please ask them to provide a select query example which one > of the current engines cannot solve, but which an engine that followed > the REAL path would be able to solve. I'd venture that if you can find > such a real example with real-world application, then mainline DB > engines would quickly incorporate/adopt it. Controversy requires only that there are outspoken people on both sides of an argument, not that either side has any real points. You seem to have assumed that any controversionists (your invented word) were on my side, whereas I intended to discourage the more reasonable of those on the other side from wading in. > I can't speak for everyone, but it is my sincere belief that every DB > engine, at the start, intended to be "The One" Do you remember that there was once a short-lived product actually called "The Last One"? > that was going to be closest to the relational model and/or the SQL > standard Just "or", the standard itself contradicts the model. > - right before reality intervened. Reality can be cruel and illogical and take no regard for the best interest of anyone involved. At which point we should stop being quite so OT before someone stamps on us ;-) Eric -- ms fnd in a lbry _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
