What Would Your Ideal Database Look Like?

Posted on by Erik Darling

Laggage

I’m often frustrated by things that are either not implemented well, or at all, in SQL Server. I don’t want to make a list here, because I don’t want to dissuade anyone from commenting, but here’s a picture of me reading it.

AND THEN

And yes, the grass may always be greener on other platforms. Oracle and Postgres have some pretty amazing things in them that I think could solve some pretty big problems, and fill some pretty big holes for developers.

Anyway, this post is about you, dear reader.

If you could design your ideal database to work with, what would you do differently than what SQL Server does?

Thanks for reading (and hopefully commenting)!

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that and need to solve performance problems quickly.

Related Posts

7 thoughts on “What Would Your Ideal Database Look Like?”

  1. I would like a database with:
    – a fine shrink, not the one that actually exists
    – a better maintenance plan , for example the Ola Hallengren one
    – possibility to move the database files without restarting or putting offline the database
    – better reports in managment studio
    – more configurable options such as default on RCSI ….
    – so many others

  2. SQL Server with the different replication types like mongo (replication meaning HA), table level restore like PG or other open source DBs, array data types, true JSON integration, easier use of procedural languages like PG, Powershell job step that actually lets you use more current PS version, Extended events that didn’t require XML super ninja skills.

  3. basically SQL Server, but where T-SQL gets as much love and attention as C#, and where select * from sys.messages where text like ‘%not supported%’ wouldn’t return a hundred million rows

  4. Object level restores, more HA/Replication options like Michael mentions, toss empty pages automatically so there’s no need for shrinks to begin with, parallelism across the board – no weird surprises that some commands are always single threaded (such as rollbacks and shrinks and some types of inserts), an automatic corruption healing option without having to maintain a second database/server even if it means the database uses twice the space (just trying to avoid administrative overhead for instances where you don’t need a second server for any reason but would like automatic healing). There’s more I can’t think of right now.

    1. And more maintenance options like others have mentioned, and more native monitoring options. Basically anything in which there is a HUGE following out there such as Ola’s scripts, and all the monitoring applications, all the data compare suites, etc.

      All of those products are indicators of features that the native system is lacking. Of course, this would mean that the SQL Server team would likely need to grow, but customers may be happier if all these things were integrated instead of DBAs having to piecemeal a solution from various vendor apps and scripts. Then maybe we would have more time to work on the actual databases and design rather than spending time on scripting tools and buying apps to figure out what the server is doing 🙂

      But this is all wishful thinking and would never happen.

  5. When moving over from Oracle to work with SQL Server I mostly misses the Oracle take on locking, a more robust optimizer that don’t get confused so easily and finally PL/SQL! While T-SQL is some kind of scripting language PL/SQL is a full fledged programming language like a solid exception handling and packages.

Comments are closed.