On Thu, 2006-06-08 at 07:21, dananrg@xxxxxxxxx wrote: > I'm reading, and enjoying immensely, Fabial Pascal's book "Practical > Issues in Database Management." > > Though I've just gotten started with the book, he seems to be saying > that modern RDBMSs aren't as faithful to relational theory as they > ought to be, and that this has many *practical* consequences, e.g. lack > of functionality. I generally find the arguments that modern RDBMSes aren't faithful to relational theory to be much like the old arguments about how many angels could dance on the head of a pin. The single most commonly trotted out one is that in relational and set theory, duplicates are not allowed, but modern RDBMS systems allow duplicates, unless you design your schema to reject duplicates on purpose. While it would sometimes be useful to have my database automatically declare all tables to have a unique index across every field in a table, I know that performance wise this could be a disaster for some data sets, and often it would have no real value. Not that they don't have a valid argument, I just think it's a kind of petty argument. The other arguments that show up generally have to do with having the ability to get the same data results in more than one way (i.e. a non-deterministic methodology) which other query languages seemed to have solved in the past. OTOH, PostgreSQL descended from a database that used the QUEL query language, and it seems a bit hard to find other QUEL databases. SQL may not be perfect, but it is fairly ubiquitous, and that makes porting to or from one SQL db to another moderately easy. To me, the real argument is, "Is SQL so lacking that it should be replaced". In what REAL measurable ways is SQL lacking so badly we should toss it and start over? It's not perfect, that's for sure. But what's the investment on starting over, and the possible traction of a non-SQL database in a largely SQL driven market?
