The ghosts of Microsoft SQL Server past, present, and yet to come: The Reg chats to Azure Data man Rohan Kumar Everyone has their favourite when diving into the tub of SQL Server - for some it's a chewy hard toffee that delights, for others it's a thin choc shell crammed with overperfumed fondant. Microsoft's Rohan Kumar says his preferred version is SQL Server 2008. El Reg spoke to Kumar, corporate vice president for Azure Data, about …
I honestly don't think it matters which of the more popular SQL servers you use as long as it supports all the features you need for your project. If you're backing an application of any kind you only really need the basic functionality because you can build anything you like inside your application.
SQL Server, MySQL/MariaDB, Postgres, Oracle, even SQLite most of the time. Other than remembering a few syntax differences it doesn't really matter to me. I've used them all and none of them are really horrible, except Oracle's pricing of course.
To be fair, the original licensing requirements for SQL Server (which essentially meant if you used it to support a web service you had to have a licence for every possible user of the website) forced me into the sub-optimal position of having to use an Access database instead and Jet drivers that leaked memory and locked up to the extent that the web server had to be restarted several times a day. I moved swiftly on to PostgreSQL, though in its more recent incarnations SQL Server became a much more credible candidate for a lot of applications.
SQL Server has been both useful and affordable for a relatively small proportion of its life.
SQL server in itself is one of Microsoft's better products. But.
- The possibility to run it on a sane OS came years after the others ate this part of the cake
- Licensing (for use on your own infrastructure) seems to be modeled around Oracle: Nobody understands it.
So thanks, but no thanks.
My personal view on MS SQL is that I do not relish supporting any version of it. I'd argue that for most installations, it is overkill for what is needed. I regularly get called upon to run updates for a well-known accounting system which uses MS SQL as its database engine simply because there is usually an incomprehensible error or two that prevents normal operation thereafter. One recent update involved migrating to a newer version of MS SQL which was complicated by lack of space on the C drive of the server.
The acid test for me when writing or recommending software is: how quickly can we get back up and running should some catastrophe occur? This risk assessment needs to take into account versions of program, ditto data, licencing issues, operating system it can run on, access to installation images, etc., etc. If forced to get a new pc off the shelf from a nearby retail outlet to get the business up and running again, how quickly will we be in a position to process data again, including satellite pc's, without having to resort to software vendor support for installation procedures peculiar to their system as these situations often unfold outside normal office hours? In the above case the support hotline is second to none when speaking to them, but it can take several hours to get to that stage.
One point to bear in mind to ask is if it is possible to schedule such updates so that they are done at a time to suit everyone? If the cloud is where the data is stored, is there this option, or are you forced to update when it suits the vendor's agenda, rather than yours? Accountancy firms in particularly have bad times to be thinking about doing updates, such as the forthcoming Self Assessment deadline.
If you use its amazing JSONB data type, you get something very MongoDB-like alongside relational just out of the box. And amusingly when they launched it it was faster than MongoDB at the only thing MongoDB does, while still also being a fully fledged relational database.
MongoDB then rewrote their engine to make it faster than this little corner of Postgres, so that's good.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
