Earlier quoted context omitted.
I know numerous guys on the SQL Server team and it actually causes me a bit of anger when I read a clueless statement like that, for the author I feel sorry for his ignorance; the anger comes from the fact that lots of clueless people will actually read this and believe it to be authoritarian because of the verbosity of it alone.
The SQL Server group (and their product) is one of the very few things in Microsoft that has earned my deepest respect. Not Windows, not Exchange and, certainly, not ShamePoint. I frequently rank Microsoft's product line as follows: 1 - Natural keyboard - the one there is no reasonable replacement for (the kinesis keyboards are 5 times as expensive). If there is a reason my none of my machines is 100% Microsoft free,…
PostgreSQL vs. MS SQL
51–60 of 106 posts
Re: PostgreSQL vs. MS SQL
#52Earlier quoted context omitted.
> I mean, seriously if you are going to put the time and effort into a long document like this, don't be so blatantly bias. It's also totally counterproductive. If you tell me to use something and you start telling me things that aren't true I'm going to be deeply skeptical of your possibly-valid points if I know you're either ignorant or dishonest in some cases.
this is, well, particularly apropos for keithwarren -- I had no end of pain getting csv into sql server; pg handles it fine
It is one thing to say 'SQL Server takes some effort to import CSV files with X scenarios'; but to say it does not import them at all?
Re: PostgreSQL vs. MS SQL
#53I scrolled to a random page. It was totally absurd, stopped right there. "Crucially, because open-source software tends to be written by people who care deeply about its quality (often because they have a direct personal stake in ensuring that the software works as well as possible), it is often of the very highest standard (PostgreSQL, Linux, MySQL, XBMC, Hadoop, Android, VLC, Neo4JS, Redis, 7Zip, FreeBSD, golang, P…
I didn't even get that far. Clearly SQL Server definitely wasn't suitable for our 4.5TiB of LoB financial data in 500 tables for the last 15 years and was such poor quality that we have absolutely no problems whatsoever running two 48 core Xeons with 64GiB of RAM at 50% load 24/7... Edit: I live down the road from the guy: Matthew Byrne (address removed, but lives in Shepperton, UK) Please have enough balls to put yo…
Re: PostgreSQL vs. MS SQL
#54Earlier quoted context omitted.
I didn't even get that far. Clearly SQL Server definitely wasn't suitable for our 4.5TiB of LoB financial data in 500 tables for the last 15 years and was such poor quality that we have absolutely no problems whatsoever running two 48 core Xeons with 64GiB of RAM at 50% load 24/7... Edit: I live down the road from the guy: Matthew Byrne (address removed, but lives in Shepperton, UK) Please have enough balls to put yo…
Just curious as to why the article merits this type of vitriol. I'm a .NET/SQL Server guy from the states, so I have no skin in this game, but it just seems to me that this is unwarranted.
Not only that, the site is designed to intentionally hide the author obviously because being accountable for an opinion is probably bad for them in this case.
Re: PostgreSQL vs. MS SQL
#55Earlier quoted context omitted.
Just curious as to why the article merits this type of vitriol. I'm a .NET/SQL Server guy from the states, so I have no skin in this game, but it just seems to me that this is unwarranted.
Because most of it is circa 1998 Slashdot-esque content which really isn't constructive and only damages what little faith people have in this industry even further. The article itself is vitriol. Not only that, the site is designed to intentionally hide the author obviously because being accountable for an opinion is probably bad for them in this case.
"...being accountable for an opinion is probably bad for them in this case." Same for you as well, it seems.
Re: PostgreSQL vs. MS SQL
#56Earlier quoted context omitted.
> First, you can import/export csv's. Hell all you need to do to export, is right click the view and hit export, then select .csv. Are you saying there is no programatic interface for exporting csv? You must rely on the administration tool to generate the csv for you???
@sergiosgc Nope. There are several ways of doing this. Using the GUI is the easiest, and the most common method. You can use SSIS, or the bcp command. For example: bcp "SELECT blah... FROM blah" queryout C:\..\blah.csv -c -t, -T –S
Re: PostgreSQL vs. MS SQL
#57Earlier quoted context omitted.
So that is a "no" then? You make a blatant argument from authority and then when asked to affirm your opinion with facts rather than claimed qualifications you refuse (saying "read the other posts" is a refusal if I've ever seen one).
In all honesty it would take hours to write a proper rebuttal. There are many factual errors but there are also many errors that are mostly incorrect. CSV import/export is one of the first things he calls out and he never mentions BCP or SSIS, which are the methods for CSV import in SQL Server. It would be like saying Apache does not support SSL - it is just factually wrong.
Re: PostgreSQL vs. MS SQL
#58There is so much here, it is so verbose...so religious. There is the appearance of facts, but mostly it is bias by omission. Take for example the CSV complaints..."MS SQL Server can neither import nor export CSV. Most people don't believe me when I tell them this". This is just false, patently and obviously false. BCP and SSIS, both part of SQL Server have excellent support for importing and exporting flat files. I d…
They likely should have said "standards compliant CSV." I've worked a lot with CSV (too much!) and let me tell you Microsoft's tools are simply awful at following the CSV standard. Excel in particular drives me up the will. Plus the automatic inferences in Excel break all kind of things. Have a six digit number? Randomly a date. Have a UPC? Going to corrupt it in numerous ways (leading zero stripping, converting to s…
Re: PostgreSQL vs. MS SQL
#591. HA, via replication, clustering, etc. are all fantastic as well as easy and trivial to setup. Once PG can offer a simple little wizard and setup replication, or shared-nothing clustering with automatic fail over, awesome. Or even tx log shipping with a few clicks.
Instead, last I tried (9.0 I think), pg drops you off with some weird system that makes you run shell as a specific user, where you run generic sounding commands. Oh and some default config that seemingly has some bad defaults you probably should change.
2. Overall, MSSQL makes it easy to run a DB. I was doing a billion transactions a day (each which wrote to a few tables and also included a real ACID balance update), and I didn't need a full time DBA or have to have particularly awesome experience beforehand. With pg, I sorta got somewhere, but I had little confidence
3. Development is far superior on MSSQL. Supporting other languages is a null point, because they aren't running as part of the query execution engine. That is, there's no real difference in using Python inside PG versus an external client, as far as I could tell. You still had to submit queries and make a transition. So TSQL seemed far nicer to work with than plpgsql. Although, the record types in pg were much nicer I'll admit. Another annoyance: pg didn't offer multiple returnsets in many situations. This made it awkward to run a sub function that needed to return results from different tables as separate queries. And the perf tools and UI was just so, so much better.
4. There'd be strange "little" features you'd just expect to be there, like materialized views, which pg simply does not have. Pg still lacks materialized views. The current implementation is essentially pointless, as it doesn't update the view automatically.
I'm very much for PG, and believe it's an important project and am trying to use it for future development. Much because Microsoft went back on its word that it wouldn't move to an Oracle-style licensing where you pay for CPU power instead of just sockets. They've also made questionable decisions with Enterprise vs Standard, putting extra cumbersome limitations. They aren't adding features like JSON or arrays quickly. And also, I think it's important to run open source and try to make sure free systems stay viable.
But MSSQL has a lot going for it, and the ease of use and built in HA options don't even seem like goals for PG. If licensing weren't in the way, and I just wanted an easy system that was capable but didn't require lots of time, MSSQL makes a strong choice.
Re: PostgreSQL vs. MS SQL
#60> "but MS SQL Server does have a bizarre failure mode which I have witnessed more than once: its transaction logs become enormous and prevent the database from working. In theory the logs can be truncated or deleted but the documentation is full of dire warnings against such action."
This belies what appears to be a fundamental ignorance of SQL Server and is not at all bizarre. If a database has been deployed in a non-simple recovery model, then the transaction log needs to be truncated as part of a backup procedure. If this isn't the case then you should have hired a/better DBA.