Well, I just think that a lot of data, most of it in practice, does not naturally fall into a table structure.
Social networks, heirarchies of inheritance, arbitrary relations between documents such as the web itself - most data is naturally a graph or tree structure.
So when you squeeze these kinds of data into tables, and do the right thing and normalize so you dont have duplicates etc, then you have a lot of SQL manipulations to get the data back out.
Relational I think has a specific meaning in terms of relational algebra the math behind normalising tabular data in 'Relational Databases' (tabular databases).
But obviously you need relations between items of data regardless of whether they are in a RDB, OODBMS or in a graph or tree structure.
I think the Key Value stores we see being so popular now have got it right, but there's some part missing - a good intuitive powerful query and update language [probably functional, definitely not SQL].
Id put it in the same category as RDF - largely unusable.
I think data is much wider than 'what can be stored in tables' - that's the whole problem.
Although all data could be stored in tables and accessed via SQL, it shouldn't be. I contend we need to optimize for the common case of tree / graph data and fidn something much better than SQL.
Comments
Well, I just think that a lot of data, most of it in practice, does not naturally fall into a table structure.
Social networks, heirarchies of inheritance, arbitrary relations between documents such as the web itself - most data is naturally a graph or tree structure.
So when you squeeze these kinds of data into tables, and do the right thing and normalize so you dont have duplicates etc, then you have a lot of SQL manipulations to get the data back out.
Relational I think has a specific meaning in terms of relational algebra the math behind normalising tabular data in 'Relational Databases' (tabular databases).
But obviously you need relations between items of data regardless of whether they are in a RDB, OODBMS or in a graph or tree structure.
I think the Key Value stores we see being so popular now have got it right, but there's some part missing - a good intuitive powerful query and update language [probably functional, definitely not SQL].
Have you looked at XQuery? It's far from perfect, but quite useful.
I also find it useful to talk about "data" as anything that's easily modeled in tables, vs "information" (table-friendly data, plus trees and graphs).
Id put it in the same category as RDF - largely unusable.
I think data is much wider than 'what can be stored in tables' - that's the whole problem.
Although all data could be stored in tables and accessed via SQL, it shouldn't be. I contend we need to optimize for the common case of tree / graph data and fidn something much better than SQL.
Is SQL also "unusable"? XQuery is quite a bit more powerful than SQL is.
RDF, on the other hand, isn't a query language. Wouldn't it make more sense to compare XQuery to SPARQL?
Well, Id say SQL is close to unusable.. it has just enough good design to explain its long life. I do respect it.
SQL is a bit like Cobol - served us well for 30 years, time to move on.