That being said, I'm always a bit surprised that SQL Server doesn't get the recognition that (IMO) it deserves. It is a pretty solid product. I was in a position to use it for years and saw it mature such that it eventually replaced legacy DB2/Adabas environments. It performed admirably and for a fraction of the price.
If the powers that be hadn't decided Oracle at all costs (and literally at all costs) against my counsel, they would have saved a lot of $$ and I might still be working there.
I'm always a bit surprised that SQL Server doesn't get the recognition that (IMO) it deserves
As someone who has spent 13 years with it and has dragged himself through multiple certification cycles, the reason it doesn't get recognition is that it's an insanely deep money pit when you have to scale it. By the time you've forked out for the (now suddenly per core rather than CPU[1]!) enterprise license, all the 3rd party backup and restore tools, numerous windows licenses and had your arse audited for license compliance, you're down a lot of cash.
Not only that, from a technical perspective, it's an absolute bastard to administer, particularly if something goes snap. It requires significantly more meat popsicles to run than a similar sized Postgres or MySQL cluster.
To be honest, it's cheaper to solve all the problems that SQL Server solves at an architectural level these days. It's no longer something special (was it ever?).
The only thing going for it these days is that it's better than Oracle.
[1] This properly fucks us on the 2008->2012 upgrade cycle as our primary machines are 4x 8 core Xeons. So that's from 4 licensable CPUs to 32 licensable CPUs. We have 4 of those machines. Bastards!
>By the time you've forked out for the (now suddenly per core rather than CPU[1]!) enterprise license, all the 3rd party backup and restore tools, numerous windows licenses and had your arse audited for license compliance, you're down a lot of cash.
SQL Server licensing is pure madness.
I will never forget sitting across from a cadre of regional level Microsoft folks who had just finished explaining the intricacies of SQL virtualization licensing.
The seemingly straightforward design we envisioned to cost perhaps $120K under any sort of reasonable, logical licensing structure attached to per socket price of SQL would actually run upwards of $1.3M to properly comply with the Microsoft licensing terms.
It wasn't even the absurd total or the ridiculous terms that were so memorable. It was the fact the Microsoft folks seemed to be as shocked at our incredulity as we were at their terms.
I got the impression they weren't used to providing more than "It's cheaper than Oracle" as justification to receive millions of dollars.
At least you got a number. A company I worked for back in New Zealand had a particularly odd architecture which didn't fit neatly into any of the SQL Server licensing structures at the time.
We asked MS what sort of licences (& how many) we'd need to purchase and were still waiting for an answer months later when I left.
I worked on one of those myself. The truly ass-backwards thing about it is that MS sales won't tell you what licenses you should buy in advance... but they'll sure as hell tell you what you should have bought during the audit.
It requires significantly more meat popsicles to run than a similar sized Postgres or MySQL cluster.
To be honest, it's cheaper to solve all the problems that SQL Server solves at an architectural level these days. It's no longer something special (was it ever?).
The problem wasn't finding a replacement for MSSQL, but a replacement for all the tools that come bundled. SSIS, MSAS, SSRS are just a few of the products that make MSSQL a powerful tool. The ability to build and process cubes in MSAS that can be browsed as pivot tables using an Excel plugin made data analysis easily accessible to the analysts at my old company.
I agree that licensing is outrageous and I tried hard to move us onto something else, but replacing the other products would have taken too much time.
By the time you've forked out for the (now suddenly per core rather than CPU[1]!) enterprise license
1] This properly fucks us on the 2008->2012 upgrade cycle as our primary machines are 4x 8 core Xeons. So that's from 4 licensable CPUs to 32 licensable CPUs. We have 4 of those machines. Bastards!
But the Core pricing is 1/4 the CPU pricing, so you're going from 4 licensable CPUs to the equivalent of 8 licensable CPUs.
I think I will stick with DB2. One person, four machines, multiple logical partitions, and nearly a hundred terabytes of data. Oh, I have a backup person.
Administration, monitoring, maintenance, and such, is all like, yeah its done.
Really I read these comments here about SQL and DB on other platforms and I cannot fathom it, I simply never experience it. The AIX/Oracle gang has half a dozen people or more doing the same work as I for their platform and I don't see the benefit.
I didn't mean to slight DB2, the 8+ versions have been pretty solid and require just about as much work as SQL Server.
However, IBM licensing was significantly more expensive than our SQL Server licensing. As for FTEs, the same DBAs managed DB2 and SQL Server simultaneously whereas we needed an entire new cohort to deal with Oracle.
"Not only that, from a technical perspective, it's an absolute bastard to administer, particularly if something goes snap. It requires significantly more meat popsicles to run than a similar sized Postgres or MySQL cluster."
Really? If you have some pro DBAs in charge you don't need mass quantities of warm bodies. (The problem is that 90% of the folks that claim to be experienced can't tell a clustered index from a cluster f__k.) You can automate 95% of the job and spend the rest of the time helping users do better.
"To be honest, it's cheaper to solve all the problems that SQL Server solves at an architectural level these days. It's no longer something special (was it ever?)."
Bullshit. I'm dealing with clients that insist on writing custom applications to do complex ETL instead of using SSIS or decent third party tool. Or wasting months writing code that reinvents SQL that's been around for decades.
>I'm dealing with clients that insist on writing custom applications to do complex ETL instead of using SSIS or decent third party tool.
I have some beefs with SSIS (which I bring up to the SSIS team lead, Matt Masson, every time we meet) but it's not as bad as so many folks seem to make it out to be. However, what I always see is a never-ending shortage of clients that write their own ETL systems that have 10-20% of the functionality, and 10-20% of the performance (and 10-20x the bugs). Even my current client seems to be doing just this.
Replacing homegrown ETL systems with SSIS, ODI or PowerCenter implementations is a great way to make money. I've seen ETL systems that folks were mighty proud of that had throughput (granted, to some very questionably modeled "data warehouses") measured in bytes/sec. Yes, bytes. We're talking 3 hours to get an 2MB file into the final fact table with some custom "framework" written in C# or Java that uses a web service for all message passing for servers within the same rack (and will always be in the same rack). Again, not necessarily the framework's fault either, just how poorly it's used, and how poor the data is modeled (in the above case, I was able to rewrite it with their tools and get the 3 hour job completing in ~50 seconds after a few days work and tearing through their framework's source code repo). The bugs you can find are fun too. My favorite was when the web service endpoints weren't reusing the same connection, so they were exhausting all the ephemeral TCP ports on the database server's TCP/IP stack -- when the job ran ~200 times faster, since the messaging was so chatty, the ETL framework was basically DoSing their SQL Server (for any service/application using a non-specific port).
Honestly, if you enjoy making things 100 - 10000x faster, live in the database world. The market will present an infinite number of opportunities for you to do so with commodity DBMSes such as SQL Server, MySQL, Postgres and Oracle. Most of it is simply cleaning up bad data modeling decisions, cleaning up a complete misunderstanding of how their database engine works, and overly complicated systems doing very simple things.
-----
I do agree that SQL Server licensing, especially when using Enterprise, can hurt. A lot. It's really set up for scale-up architectures (and Windows clustering could stand to be improved quite a bit), and if you dare deviate from that notion, you get hurt rather badly.
Yes it's horrible to administer. We have high profile DBAs. One of them was on the SQL Server team a few years back. A huge amount of work is generated for them that is unnecessary on other platforms.
SSIS is a pile of shit. It's impossible to test properly, suffers horrific deployment problems, is very unreliable and the only way to get transactional guarantees is using DTC which literally destroys your performance.
A better solution is something like spring batch / spring integration back off a queue solution.
Back in 2004, a seasoned DBA was contracted to help our team set up an Oracle cluster. He said SQL Server was pretty good, but that the problem was you had to run it on Windows. In the past, he'd been in a team of 3 DBAs who kept 100 Oracle instances running on Solaris machines in a large company. After that, he helped a small financial company with their big database problems. They had 3 full-time DBAs constantly firefighting because they were running 3 Oracle instances on Windows. After he switched them over to Linux, their problems declined dramatically.
Anecdotal, but that guy saved us a lot of time and effort because he knew what he was doing, and I'd take his real life experiences over any sales rep! I'd probably also enjoy the awesome SQL Server GUI in a *nix environment if I could have that. :)
So 2004...that experience was probably running a mix of Windows Server 2000/NT. OS's that would be teenagers/in college now. It really is a different world in the server OS space (especially in the enterprise datacenter space) now.
That's... debatable. The problem is that the Oracle portfolio is now so vast, after a decade of acquisitions targeted at "surrounding" SAP, that quality levels are very uneven across the board. Some products require constant attention from specialized personnel or they'll blow up in your face, the learning curve is always very steep, and some of them are just full of bugs. And I say that as one of those specialized folks.
Also, their licensing terms (and the salespeople who espouse and enforce them) are unabashedly, shamelessly greedy.
that's funny that you noticed the tone. It's the tone of database guys firing shots at database guys. in another life i sat through lots of these kinds of meetings
You wouldn't think they'd let the database guys write the blog posts though. ;) Especially at Microsoft, home to some of the most sanitized corp-speak I've ever read.
Interesting. I'm consulting on a project for a heavy traffic website and the SQL Server was chosen. I'm not the DB expert on the project, but when I asked about SQL Server's equivalent to Oracle RAC, I was told there wasn't anything like that. From our experience on the project SQL Server's clustering technology was pretty amateur compared to Oracle's...
Once a month actually, and only if the patches were applicable. It really is not as bad in the MS world as you think. They made great strides in both stability and security over the past 8-9 years in the server OS area.
And, I say this as someone who has literally nothing to do with them on a daily basis anymore.
Keep it running no, keep it secure yes. That is true of any production system, regardless of vendor, or should be.
Your system/business setups simply reflect this, either through clustering or planned outages.
Not sure why I'm providing a rational opinion to a snarky jab at Mircosoft, but imo, they have made fantastic progress on the security front over the past decade.
I find that updating a Windows server often requires a reboot, while other systems can usually get away with restarting the service that is being patched.
Although I'm not a huge fan of Windows, Exchange, and the like, I am a huge supporter (although not current a user - was a SQL Server DBA for a few years) of SQL Server. It is probably Microsoft's finest engineering product. Not only is it a super reliable and scalable system T-SQL is actually a user-friendly SQL dialect, and SQL Server Enterprise Manager (or whatever it's called today) is very user-friendly, too.
Although I'm a true-blue PostgreSQL believer, I give major props to the SQL Server team. In comparison, Oracle is a disaster (I was reluctant/forced Oracle 8i/9i DBA, too).
I actually was a Sybase ASE DBA for quite some time, too (spent a lot of time in the DBA trenches - Sybase ASE is my favorite SQL DBMS) and it's my understanding that SQL Server around the 2000/2005 mark was completely rewritten. Although the origins of T-SQL are Sybase, the rest of the product isn't (some of the philosophy and core architecture still is a carry-over from ASE).
This is surprisingly strong language for a couple of supposedly mature companies. I think Microsoft would have been better off with a light-hearted response that would have highlighted Oracle's reaction of being over the top and unprofessional.
As it is, it just seems like two children throwing sand at each other.
As a former 'softie, I view it as a 'rally the troops' tone. Us against them with an undcurrent of 'they're scared'.
Definitely a different tone than what MSFT normally has, but they're confident, and in a world of 7 figure license deals, it's motivation and tone setting for re-selling partners and field staff.
What kind of technology is behind Present?
In my understanding it's easy to place all data to DB/FS buffers with any DB engine and get superfast operations.
If the data is guaranteed to be in memory you can use different data structures that are even more efficient — sometimes 10x more efficient. Ask the TimesTen, SolidDB, or VoltDB folks.
In the long run what is going to hurt SQL server is the fact that it is on Windows only. And if you look at the technology trends for databases - big/midsize IT shops are gravitating towards integrated solutions(Exadata e.g) where Microsoft still relies on third party for hardware. Small shops/startups are gravitating towards commodity hardware(primarily linux based), where trend is more towards MySQL/Postgre/NoSQL, where Microsoft is lacking. And then the cloud (where Microsoft does have an early presence, but then Amazon has been there long before and Oracle is there in too)....In that context this In-Memory database technology tussle is playing out, which was clearly ignited by SAPs Hana (even though oracle had times-ten long before SAP came out with Hana). So looking at future market direction, things are not looking very good for SQL server, even though it is probably one of the best products to come out of Microsoft and currently is doing great.
It's interesting that when companies like Microsoft are politically correct, we get blast because of it. The on the flip side when they seem pretty aggressive we blast them because of it also.
Personally I like seeing facts not just words. If you're going to be aggressive about your product, fine by me, but.... where's the proof? Where are the un-bias comparison graphs? What use case are you using to prove your point? Without data they all come off looking like two politicians.
All this said, I love SQL Server but never used it at a super large scale though. What I prefer most about it are it's tools which seem to be much more user friendly then Oracles. I'm no DBA though.
Microsoft is playing its usual strategy here: start with a "toy" and slowly ascend the features/quality ladder with each release; all the while undercutting the competition on price.
That said, pretty much every enterprise database vendor will soak you for every cent you have.
Whenever folk tell me that "relational doesn't scale", I explain that it's been scaled up and out for decades. Don't believe me? Ring any Fortune 500 and ask.
... and then ask how much it's costing them. Be prepared for sticker shock.
That being said, I'm always a bit surprised that SQL Server doesn't get the recognition that (IMO) it deserves. It is a pretty solid product. I was in a position to use it for years and saw it mature such that it eventually replaced legacy DB2/Adabas environments. It performed admirably and for a fraction of the price.
If the powers that be hadn't decided Oracle at all costs (and literally at all costs) against my counsel, they would have saved a lot of $$ and I might still be working there.