We ain't in 1996 anymore, Dorothy: SQL Server 2016 proves it Microsoft has had a database since 1989, initially working with Ashton-Tate and Sybase to create a variant of Sybase SQL Server for IBM’s OS/2. But it wasn’t until 1995 that Microsoft really got serious with SQL Server 6 for Microsoft’s rock-solid server operating system Windows NT. Back then, however, engines like SQL Server …
a rock solid database: PostgreSQL that will work on rock solid operating systems as well as MS Windows.
Moreover our latest EU* project uses PostgreSQL with R and JSON - one simple vagrant file attached to an email flung around the empire has all researchers able to hack and submit.
No licensing problems, no up front costs or eye-watering downstream cavity searches.
* And probably last, I'm told. Perhaps I ought to watch the news and find out why.
A few rules:
- Fixed Volume of data (say 3TB)
- Fixed application requirements (what the DB don't do, you must do in the application)
- 10 year lifecycle
Now in the blue corner:
MS SQL Server 2016 (Whatever edition suits you, as long as you pay for it)
And in the red corner:
Anything from the open source camp. (PostgreSQL, MySQL, whatever)
Let's see, who delivers the better TPS/$
Rock solid.
Firstly a lot depends on the skill set of the staff and what is already in use…….
Then it depends on how many copies of the application will be in use, e.g. if the application is sold to 50 customers a lot more can be spend in development cost to reduce license costs.
I rather expect that if “in memory tables” and/or data warehouse functions of SQL server benefits the application a lot, that the savings in development costs will make MS SQL Server 2016 win. Otherwise I expect it will come down to what the developers/admin already know, e.g. the cost in time of them getting up to speed on a “free” database may be more then the licence costs saved unless they already have these skills.
It also boils down to the environment. If the environment is heavily loaded to MS, then there is a lot of infrastructure already in place .Net apps, Exchange, obviously AD. I've worked Oracle for almost 20 years and only recently started learning SQL Server and being able to control security for example over 75 servers and 270 databases with simple groups in AD means I don't waste time running around loads of separate systems with lots of custome built scripts, I get more time to spend learning other fun stuff. I'm not saying the MS eco-system is the dog wotnots, I much prefer to be on Unix systems ( looking forward to SQL 2016 on Linux ) and MS kit is open to abuse like any other but it has its moments.
You fail to notice that directory services and remote administration tools like Ansible are orthogonal tools, one doesn't exclude the other, and you should use both.
Having a centralized directory (aka database...) of users, groups and other resources, extensible, and accessible with a standard protocol simplifies administration a lot - you don't have to replicate the same information across many different systems. Even using Ansible or whatever to maintain them across many systems is an error prone approach which makes maintaining scripts a big risky effort.
A directory service enforces coherency, for example - you don't end up with the "HR drones" group called "HR drones" on one system, "HR_DRONES" on another, "hrdrone" on a third one, and so on. Logging, correlation and auditing becomes much easier, as controlling user accesses.
"It is unlikely to be much lamented and Microsoft says that it is dealing individually with the customers who did adopt it."
Much missed here because BI Edition was CAL licensed and Enterprise is per-core.
So my 32 core, 50 user box has just gone up from £10,000 to £100,000.
MS are indeed dealing with us individually - negotiations still ongoing but at the moment they are saying we have no choice but to pay up.
We're in the purchase cycle for two reasons.
(1) the users want zero downtime deploys (our SSAS cubes take 3 days to fully reprocess after a schema change), so that means two servers (which would have been trivial cost wise for a CAL licence) and
(2) the developers want to use many-many hierarchies in Tabular (a new feature added in 2016).
Unless I can bodge something using Dev Edition and backup/restore or swapping EBS volumes around we'll probably ditch SSAS for something like Exasol, the costs don't work out and with a fast relational engine instead of MDX/DAX there are so many more reporting tools available (Excel just isn't enough any more with a 50% mobile audience).
In all honesty I do think fondly of Microsoft SQL server, I think it's a very interesting product which has seen its technology being used in all areas. From the big SQL server environment right down to something as trivial as SqlServerCe (file based storage, which can be used within ASP).
But ever since I adapted open source variants I started to look much differently at the whole Microsoft development (or should I say release?) cycle. I started with MySQL which I use most often, but personally I prefer PostgreSQL. Here's the thing: they also have new releases, but every new release makes sense. They usually don't add features "because" but because they actually enhance on their products.
Don't take my word for it! When looking at PostgreSQL then just check the release notes for 9.6 beta.
Here I really start to get the feel of: "A new year, a new SQL server, yaaaay!". Yay, right :P
Note: this is coming from someone who still uses (and likes!) Microsoft Office 2010 and never felt the need to upgrade. So yeah, maybe I'm just biased.
You mean features other databases had for years and Postgres is just introducing now? Partitioning in the open source version is still a nightmare, for example.
Sure, for high-end, complex database Postgres still has lot to add, thereby it can stay away from more "esoteric" features other databases are implementing. For simpler databases it works, although most of its admin/dev tools are quite primitive.
Past summers are sunnier, young women were more beautiful, we were more handsome, food tasted better, and our memories allow time and distance to blur our bad experiences.
I was actually writing applications and installing/administrating with SQL Server from version 1, from a background of DEC Rdb, Oracle, Informix and Sybase on minis; and XDB, dBase and R:Base on PCs. The early MS SQL products were awful, but had the advantages of cheapness and ubiquity. It did not really mature until the total rewrite that came with Version 7. I retired between the 2005 and 2008 versions, so cannot comment on the later systems.
These days, when I need to do this stuff, SQLite works for me; or if I am advising someone who is thinking of a larger system, I show them Postgres.
There is no need to backup the cloud part of the table, Microsoft will do that for you...
That's nice.
Me drops half a key of pure Colombian cocaine into a burlap sack full of badgers, beats the sack against a brick wall until it's a flailing, screaming ball of pure rage, secures the frayed and ancient straw cord draw string with a poorly tied granny knot and throws it in the back seat of a car.
Me then gets in the driver seat of the car, on which the sunroof, radio, instrument cluster, steering, breaks, engine and exhaust system are totally buggered and goes barrelling down the autobahn at 160km/h.
This article possesses no technical information or detail as to how "new" SQLServer offers superior or even equivalent functionality including for Cloud Computing, compared to prominent databases of Oracle, Google Cloud/SpammerDB, MariaDB, latest PostgreSQL/EnterpriseDB or even advanced NoSQL object/cum relational databases and others.
Is this reason Microsoft is partially porting SQLServer to Linux. so that the "close integration" of Redhat Enterprise Linux and FreeBSD, into Azure Cloud Computing Services - official and public announcements, so that SQLServer will offer at least some measure of viable SQL database choice?
To-date SQLServer does not process the massive amounts of "spatial data" - as in NASA/weather forecasting , a standard capability of PostgreSQL/EnterpriseDB.
It is also noted that no author was indicated for the aticle. A sick and crass propaganda move.
It is also noted that no author was indicated for the aticle.
It shows up here as Mark Whitehorn
While I agree with the general thrust of your argument: this is essentially a bit of PR for Microsoft, I also know some people are really happy with the MS stack, of which SQL Server is a key part. And let's face it, if Microsoft wasn't in the mix, the world would be divided between Oracle and DB2 — fine systems but at a price.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
