SQL could be in line to be moved on from “venerable” tag to “obsolete”…
NoSQL is supposed to be "not only SQL". Why is it that you lot continue misreading SQL for RDBMS and proclaiming the end of the relational database. SQL as a language has many drawbacks and pitfalls but it isn't about to go away: for the majority of large-scale data storage systems it is the only reasonable solution. Key-value and document storage systems may have their place alongside relational ones but any attempt to replace them will require reinventing them.
Re: Oh, please
But that isn't what the NoSQL guys are usually trumpeting around. They're mostly about the "NO SQL" part, killing ACID, killing all RDBMS concepts to implement their fantasy RDBMS-free world. It's sent the wrong message out there.
SQL could be in line to be moved on from “venerable” tag to “obsolete”
The latest proclamation of Beaucoup Harem?
While the syntax of SQL is regurgitated crap, its power is going to be with us pretty much forever (hopefully, with an updated Syntax. Datalog looks very nice...)
I randomly recommend the Jooq blog for items of interest.
>The latest proclamation of Beaucoup Harem?
I can't decide whether you mean Boko Haram or Procol Harum....
SQL is perfectly capable of expressing multidimensional data -- create table FiveDee ( int x, int y, int z, int temp, int humidity) -- see, a 5-tuple, instant dimensions no problem.
The wiki page <http://en.wikipedia.org/wiki/Rasdaman> gives some interesting examples but I can't see exactly what problem this is solving, whether some theoretical limitation in sql (unlikely) or a practical one (perhaps physical storage access due to sheer size). In any event, it'll be worth keeping an eye on this.
@BlueGreen - I think the idea would be along the lines of the GIS coordinate model so the fields in your tuple are themselves tuples (or possibly even tuples of tuples) and the calculations that may be associated with them.
You mean like each field would be a foreign key? isn't that sort of the whole point of a relational database?
the rationale is probably similar to that of MDX
MDX doesn't solve any fundamental problems compared to SQL (pretty much any MDX statement on a cube can be rewritten as a SQL statement on a bunch of tables), but makes querying this type of data easier and opens room for performance improvements in the DBMS (columnar storage, sparse data, ...)
The main difference with MDX seems to be that MDX is an entirely new syntax, with it's own limitations (only one cube, ...) while MDA seems to be more of an extension of SQL.
It looks promising indeed.
No, I'm not talking about abusing arrays to create enums. But when an array is your datatype, all operations on it will be working with the array rather than its component values. Calculating the distance between geospatial coordinates is one example of this, but there are plenty of others in other scientific fields.
It's not about storing data, but about querying it. For instance, using your example, give me all contiguous points starting at X,Y,Z that have humidity > 50%. For some definition of contiguous. This represents an entire category of problems easily handled through tiling (into progressively smaller result sets), either iteratively or recursively, which lends itself to distributed queries.
This sounds more like an extension to SQL. Something that a crafty devel might be able to do with the existing language today. But add it as a 'standard' way of doing array ops and make everyone's life easier than dealing with multiple custom approaches.
Could be a good thing. But I don't see where this obsoletes SQL.
Can't wait to see the mess produced by real life devs using this.....
FROM MRI AS img, Masks AS m
WHERE some_cells( img > 250 AND m )
SELECT png( c[ *:*, *:*, 100, 42 ] )
FROM ClimateSimulations AS c
If these are the simple examples, then judging by many of the appalling database designs and resulting SQL queries I've seen over the years, the resulting code in real life applications will probably be a complete horror show. And seeing how SQL has survived every attempt to "improve" an already mathematically complete solution to the problem of relational data over the past decades, I wouldn't be betting on this to succeed - see XQL, the query language for XML documents that was going to blow away the whole relationlal database thing for a good case in point.
SQL MDA support under discussion for several years
The SQL standards committee (more accurately ISO/IEC JTC1 SC32 WG3 Database Languages) has been looking at enhancing support for Multi-Dimensional Arrays for two and a half years. The SQL/MDA specification has now matured enough that we formally agreed to progress it (as soon as some additional work is accomplished). Two of the big benefits of the proposed support for multi-dimensional arrays are the ability to have operators implicitly iterate across dimensions and the ability to retrieve only a subset (slice) of a multi-dimensional array or of a sequence of multi-dimensional arrays. These capabilities are significantly more powerful than could be achieved with base tables or the existing array support.
As an SQL techno-geek, I think the muti-dimensional array capabilities are really cool!
Keith W. Hare
Convenor, ISO/IEC JTC1 SC32 WG3 Database Languages