Sufficiently Smart Database

Perhaps "sufficiently smart RDBMS" would be a better term.... but a SufficientlySmartDatabase is a database with numerous mystical quantities, yet to be implemented--yet often spoken of as it if exists (or is about to be available RealSoonNow).

Qualities of SufficientlySmartDatabases:

Sufficiently good at transaction analysis that a DBA never needs to denormalize schemata, yet performs as well as an optimally-denormalized (for performance reasons) schema.

I'll settle for one which offers enough LogicalPhysicalSeparation? that the DBA can change the physical storage without affecting the logical model (UpdateableViews?, clustering [as in Oracle], MaterialisedViews? and query optimisation across federated databases all help here, but AFAIK no production quality RDBMS does enough yet). Then we won't ever have to talk about "denormalising for performance" or "star-schemas" ever again.

QueryOptimizer? which allows application programmers to structure queries in any form that pleases them, without adversely affecting performance.

Yes, this is an important part of maintaining LogicalPhysicalSeparation?. A corollary is "stop inventing new SQL syntax for special cases you want to be faster, and just make the optimiser recognise them when written in standard SQL (e.g. quota queries). (Or use a different relational language that makes it easier, instead of SQL -- I'm not wedded to the language but to the model.)

Administration-free; only needs a trained monkey to load and unload tapes for the nightly backup.
- Backup tapes can be stacked cartridges that are loaded by a machine from one hopper to the next. If the hopper is cart-connectable, a human only has to move the cart to storage when done rather than mount or plug tapes.

Not the highest priority, I would think -- I don't mind paying an expert to tune a thing with lots of knobs. I just don't want that tuning to break my apps or compromise my data. Of course, SelfTuningDatabases (RDBMSs) would be nice to have...

Takes scalability to the next level, in both directions. Capable of managing (on appropriate hardware) every bit of knowledge known to Man, also capable of scaling down(MinimalTable) so that it can serve as a suitable replacement for low-level data structures like lists, sets, arrays, queues, stacks, etc; without a significant degradation in performance.
- I think this is mostly a matter of protocol coordination so that different implementations can be supplied.

Agreed -- I want to have relations in my application code too, but the library/product that allows doesn't need to share any code with the Oracle 28j server that self-tunes blah blah. As long as the _model_ scales (which it does), and the API is consistent, I'm happy with multiple implementations. An open question is how much of the "full RDBMS" functionality do you want in MinimalTable -- how important is log-phys separation, for example, given that we are using it at a low (i.e. close to physical) level?