Re: The SQL Empire Strikes Back
That's me:
https://www.linkedin.com/in/matthewtokeefe/
I preferred my previous handle but Oracle policy does not allow anonymous posting on social media. I thought that people could find my ID through the handle, but apparently not.
In any case, like any big enterprise company with a complex product line, pricing, and organization, it's hard to make every customer happy. I once accused a good friend of mine of being an Oracle hater and he said "nope, we hate all our enterprise vendors equally". Unsurprisingly, the top concern of almost all customers I talk to these days is the out-of-control, opaque pricing of the leading cloud provider; highly variable OPEX costs are generally unacceptable to businesses, so this will be a limiter for that provider in the future. Oracle, in contrast, has much more predictable and stable cloud pricing, plus SLAs no other vendor provides.
But I think cloud really changes the game for how Oracle interacts with customers and how you use our products. Cloud is forcing every company to become more relational and less transactional. I personally think that is a good direction for Oracle, because our product line and technology is so good. Seriously, there is so much fixation among The Register readers on the past and that somehow anything older than a few years is stale legacy technical debt that has to be removed. And yet... this is precisely the view that led many down the path of map/reduce, mongodb etc that is clearly kind of a dead end. That work was supposed to be "post-SQL", but in their arrogance their ignored all the hard problems SQL solved via these features:
Bulk loader -- to transform input data in files into a desired format and load it into a DBMS
Indexing -- for fast queries
Updates -- to change the data in the data base
Transactions -- to support parallel update and recovery from failures during update
Integrity constraints -- to help keep garbage out of the data base
Referential integrity -- again, to help keep garbage out of the data base
Views -- so the schema can change without having to rewrite the application program
and tool support is lacking:
Report writers (e.g., Crystal reports) to prepare reports for human visualization
Business intelligence tools (e.g., Business Objects or Cognos) to enable ad-hoc querying of large data warehouses
Data mining tools (e.g., Oracle Data Mining or IBM DB2 Intelligent Miner) to allow a user to discover structure in large data sets
Replication tools (e.g., Golden Gate) to allow a user to replicate data from on DBMS to another
Database design tools (e.g., Embarcadero) to assist the user in constructing a data base.
From the recent Spanner paper from Google, which is multi-page mea culpa basically pointing out they should have supported SQL from the beginning:
“While these systems provided some of the benefits of a database system, they lacked many traditional database features that application developers often rely on. A key example is a robust query language, meaning that developers had to write complex code to process and aggregate the data in their applications. As a result, we decided to turn Spanner into a full featured SQL system, with query execution tightly integrated with the other architectural features of Spanner (such as strong consistency and global replication).”
"The original API of Spanner provided NoSQL methods for point lookups and range scans of individual and interleaved tables. While NoSQL methods provided a simple path to launching Spanner, and continue to be useful in simple retrieval scenarios, SQL has provided significant additional value in expressing more complex data access patterns and pushing computation to the data."
That is why Google, Amazon, and Microsoft now aggressively support full SQL in their clouds. SQL has a great future because just as software is eating the world, SQL is eating all the data created in the world. Oracle's unmatched implementation of SQL which runs autonomously in our cloud, with all infrastructure (patching, security, configuration) and performance optimization done automatically, means it will be much easier to consume Oracle database and add business value with much less adoption friction and complexity. It's truly a game changer.
So my advice is: be strategic. Consider Oracle as an option; hold our feet to the fire; ask the terms you want and see if you can get them. Even if you cannot, see if the business value add still overcomes the extra cost required. But when you do, make sure you add in all the management and complexity costs associated with NoSQL so it's a fair comparison. There's a reason Google, Microsoft, and AWS are all strong supporters of SQL now, so you will be in good company.