RE: Oracle 13
Date: Wed, 5 Nov 2014 12:04:25 -0800
Message-ID: <BLU179-W387A881A2E035F01AD3E26EB870_at_phx.gbl>
re: Right on top of my list and easiest for Oracle to do is query plan stability using actual query plansEven better (and equally simple for Oracle) would be relational algebra and relational calculus: i.e. NoSQL. SQL was intended to be a user-friendly language for "accountants, architects, and urban planners." (http://faculty.cs.tamu.edu/yurttas/PL/DBL/docs/sequel-1974.pdf)The full quote in context: "There are sane users whose interaction with a ccmputer is so infrequent or unstructured that the user is unwilling to learn a query language. For these users, natural language or menu selection seem to be the most viable alternatives. However, there is also a large class of users who, while they are not computer specialists, would be willing to learn to interact with a computer in a reasonably high-level, non-procedural query language. Examples of such users are accountants, engineers, architects, and urban planners. It is for this class of users that SEQUEL is intended." When I find a magic wishing wand perhaps. Iggy
From: iggy_fernandez_at_hotmail.com
To: tanel_at_tanelpoder.com; oraclealchemist_at_gmail.com
CC: patrice.boivin_at_gmail.com; oracle-l_at_freelists.org
Subject: RE: Oracle 13
Date: Wed, 5 Nov 2014 11:13:15 -0800
re: Oracle XIII: Return of Investment
Norgaard’s First Law is “Whenever something reaches a state of perfection, i.e., where it becomes stable and very productive (in other words, saves time and money and effort), it will be replaced by something more chaotic.” (Q2 2006 issue of the ODTUG Technical Journal).
Another Mogenism: Since Oracle 7.3, that fantastic database has had pretty much everything normal customers need. (August 2011 issue of the NoCOUG Journal http://nocoug.wordpress.com/nocoug-journal-archive/) The full quote in context is: "Since Oracle 7.3, that fantastic database has had pretty much everything normal customers need. It has become more and more fantastic; it has amazing features that are light years ahead of competitors—and fewer and fewer are using the database as it should be used (they’re using it as a data dump, as Tom Kyte said many years ago), so the irony is that as the database approaches a state of nirvana (stability, scalability, predictability, diagnosability, and so forth—fewer and fewer are using it as it should be used (in my view), and more and more are just dumping data into it and fetching it."
I disagree with what Mogens said about Oracle Database having pretty much everything normal customers need. Here is my wishlist for Oracle Database XIII.
Right on top of my list and easiest for Oracle to do is query plan stability using actual query plans (not a collection of hints) and avoiding re-optimization (unless the plan becomes invalid). Either by using shared libraries like IBM DB2, linking them into the kernel like VoltDB, or attaching them to queries like Microsoft SQL Server.
All functionally equivalent queries should have the same query execution plan.
Sharding, replication, and failover capabilities that are as performant and easy to use as those offered by NoSQL products.
Eliminate the decades-long confusion between logical and physical. CREATE TABLE should not mean a physical segment. Denormalization becomes a good thing when physical is docoupled from logical. Store as BLOB, CLOB, RAW, XML, or JSON and present as normalized relational. Better performance for nested tables; that is, they should be stored inline not out-of-line and referential integrity should be supported. It should be possible to store tables in multiple ways simultaneously: e.g. IOT, hash cluster, table cluster, heap. An index is a table projection so it should be posible to store a particular in multiple ways simultaneously, Btree, hash cluster, table cluster, and even heap. Materialized views should be fast refreshable on commit without requiring a "JI" lock (if an index can be updated without a JI lock, then why not a materialized view)
Support for CREATE ASSERTION. Already available in the guise of materialized views but requires a JI lock so unscalable.
Close the write-skew gap in support for serializable transactions (Postgres has done it http://wiki.postgresql.org/wiki/SSI)
No bugs
Unbreakable (no bugs)
But if wishes were horses, I would ride.
Happy Wednesday everybody.
Iggy
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Nov 05 2014 - 21:04:25 CET