July 4, 2015 at 11:04 am
Comments posted to this topic are about the item I Feel Like a Magician
July 5, 2015 at 11:41 pm
Hi Steve,
I enjoyed your article and I have a few observations regarding it...:-)
1. I have worked with Relational databases since they were invented and publicly available. (I attended the second SQL course for DB2 at IBM in Reading, England, in 1983.) During that time, I have worked with DB2, MS ACCESS, System 2000, MySQL, Oracle, PostgreSQL, and SQL Server, plus a number of Hierarchic and Network model databases. SQL Server has nothing to apologize for; it is an excellent implementation of the Relational model.
2. I had major problems with PostgreSQL when trying to use it (at a client's insistence)with Fujitsu COBOL (which requires access through ODBC). The ODBC driver was broken and no-one would take responsibility to fix it. Eventually, I persuaded the client to move to SQL server and that's where they are to this day. Open source is a great idea and I support it, but Microsoft back their products and stand by them. That is a very important factor for those of us using RDBs commercially.
3. People who are using SQL as a development language may perceive differences in features of the language implementation and feel that some other implementation has something they don't get with MSSQL, but it is rarely a show-stopper and the thing to remember here is that most sites running an RDBMS are NOT developing in SQL. They will be using Java or C# or C++ or even COBOL. Their RDB is a REPOSITORY which they manage through application code.
4. All of the in-house development in our company uses C# and SQL Server. It was therefore a very natural progression to move to LINQ as the "data manipulation" language. We have tools that generate a Data Access Layer (DAL) from old COBOL legacy and that DAL can utilize embedded SQL OR LINQ. The DB access is generated for us as a separation layer comprised of Classes (objects) that handle CRUD operations for each set of tables on the DB, so we really don't care what features of SQL are in one RDBMS implementation as opposed to another. For new development we simply invoke the appropriate method of the appropriate DAL object (legacy tools do this automatically when the legacy code is transformed to the new technology) and can also write new views into the DAL if that makes sense. I have been astonished by LINQ and we won't go back to SQL as a language. Our applications (old and new) no longer contain embedded SQL (or LINQ) and all of this is moved to the DAL objects.
BOTTOM LINE: SQL Server is an excellent product and is well supported by the vendor. (To be fair, I can't think of ANY RDBMS which I would term "bad" these days; such software wouldn't be around long...) Your concern that some people might consider moving to other RDBMS because they have more fluff for SQL programmers, is, in the broad scheme of things, unlikely, in my opinion.
I see LINQ as the future and that means SQL Server (primarily), (other RDBMS are getting LINQ now also).
For us, the use of embedded SQL is obsolete. We maintain knowledge of SQL so we can keep LINQ honest, but we have never needed to interfere with what LINQ does.
Cheers,
Pete.
July 6, 2015 at 4:25 am
Very nice response to the PostgreSQL article. I've just come off a year+ of MSSQL from 15+ years of Oracle and his points rang very true. However, my main complaint is that MSSQL forces you to SSIS or the CLR if you want to use some sophisticated functionality like regular expressions. The problem with that is that you lose the SET operations and have to go to RBAR. Over and above any kvetching, that's a serious deficit that I don't see getting fixed anytime soon.
July 6, 2015 at 5:27 am
BOTTOM LINE: SQL Server is an excellent product and is well supported by the vendor.
Not the point the article writer is trying to make. He is a data analyst like myself, and recently experienced with more databases than just SQL Server. (It's more than a crappy ODBC driver for a crappy language.)
The point is that for a system you have paid $$$$$ over the years for multiple versions there's a lot of "magic" , "WTF?" and basic functionality that hasn't been fixed or tweaked. In fact a lot of these issues have been brought up by beginners and pros alike, only to be ignored or dismissed for years if not decades. And the point is that you can get around a lot of these issues by using software that work as well or better in many situations that you don't need to spend $$$$$ for.
I use both SQL Server and OSS. I find the main reason that clients use SQL Server is that is from Microsoft and the application vendors use it for the same reason. (Most of them don't have the experience to manage it well, so it really doesn't matter what they use...) I really want to love SQL Server, but I do find myself stepping outside of the MS toolbox to get jobs done in a timely matter instead of fighting the CSV issues or the SSIS GUI or the crazy hoops of SSRS.
There's a whole universe of tools that work well with data that aren't necessarily from Redmond. Parts of Microsoft recognize this and you see changes like including R, open sourcing .NET and using git. Separating SSMS from the core SQL Server product is a good step. Now if we can get someone to listen and fulfill some of these other pending issues, I might feel better about spending more time and $$$$$ on SQL Server.
July 6, 2015 at 6:11 am
We've been investigating PostgreSQL recently (mostly due to the cost of upgrading our SS2005 instance) and I ran across that very article.
The author makes some good points, but only addresses it from a programming perspective, which as anyone here knows, is NOT the sum total of a database engine or platform. For example, as I understand it, the pg_dump backup can't be used to do a point-in-time restore. A completely different method is required. That makes a *big* difference from an administrative point of view.
Point being that by and large programmers I talk to have very little understanding of database administration (there are some notable exceptions). If the author likes Postgres for whatever reason, good on him but I would much rather see a well-thought-out discussion of the strengths and weaknesses of both platforms rather than "MS bad, Postgres good".
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
July 6, 2015 at 7:31 am
Handling technical debt in any system is a constant challenge. Where I see the most debt in open source is the non code related issues of design and usability.
We have a lot of Oracle licenses that need to be reevaluated with either SQL Server, MySQL or PostreSQL. This was a good point of view to take under consideration.
412-977-3526 call/text
July 6, 2015 at 7:46 am
The referenced blog post was clearly written by someone who primarily works with PostgresSQL but occasionally has to context switch to SQL Server. The arugments that PostgresSQL has better documentation, is more reliable, or that the language syntax is more "egonomic" are particularly specious. The amount of documentation and community support for SQL Server on the internet is vast and arguably better than any other database platform.
The only compelling arguments presented, the ones that should be cringeworthy for the Marketing department at Microsoft, are that unlike SQL Server, PostgresSQL is cross-platform, and you can acquire non-handicapped production capable releases of PostgresSQL for free.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 6, 2015 at 7:58 am
Comparing computer languages is a lot like comparing any other type of language. If you're ever at a bar with a group of spanish speaking friends, and want to spark a lively and humorous conversation, then pose a question about the origins for gender based articles in the spanish language. Many spanish speakers will blink as if the concept of it's origins or rules simply never occurred to them. Some nouns are masuline while others feminine, and you learn the gender when you learn the word. If there are half a dozen people present, you'll get half a dozen answers, but the general consensus is that there are no hard and fast rules governing it... that's just... the way it is.
http://www.drlemon.com/Grammar/gender.html
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 6, 2015 at 8:41 am
Point being that by and large programmers I talk to have very little understanding of database administration (there are some notable exceptions). If the author likes Postgres for whatever reason, good on him but I would much rather see a well-thought-out discussion of the strengths and weaknesses of both platforms rather than "MS bad, Postgres good".
The author admitted his bias and is coming from a prospective of a Data Analyst. Administration is a topic of a different nature, but in defense of the author, it's not what he's discussing. (Realize I'm not discussing an OLTP system nor administration of either DBMS in my response.)
(You probably don't have complete content and knowledge to judge his situation unless you have a similar role and recent experience with the same tools, both SQL Server and PostgreSQL. (I'm a developer, analyst and admin on Windows and Linux currently.))
The fact it's often easier to do analysis with OSS tools, both database, applications and programming wise isn't lost to Microsoft. Notice the current trend towards OSS, R, git and supporting Linux in Azure. (Which is awesome since I like using the best tools from all worlds.)
July 6, 2015 at 8:47 am
The only compelling arguments presented, the ones that should be cringeworthy for the Marketing department at Microsoft, are that unlike SQL Server, PostgresSQL is cross-platform, and you can acquire non-handicapped production capable releases of PostgresSQL for free.
How about the fact that it's easier to maintain ETL applications with tests and source control than it is to train folks and support SSIS? Plus you don't have to buy additional licenses?
July 6, 2015 at 8:51 am
chrisn-585491 (7/6/2015)
The only compelling arguments presented, the ones that should be cringeworthy for the Marketing department at Microsoft, are that unlike SQL Server, PostgresSQL is cross-platform, and you can acquire non-handicapped production capable releases of PostgresSQL for free.
How about the fact that it's easier to maintain ETL applications with tests and source control than it is to train folks and support SSIS? Plus you don't have to buy additional licenses?
You don't have to use SSIS and can instead hand code your ETL in SQL Server, if that's what you feel most comfortable with. There are folks who successfully use SSIS every day; what they have is a pattern that works.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 6, 2015 at 9:14 am
chrisn-585491 (7/6/2015)
Not the point the article writer is trying to make. He is a data analyst like myself, and recently experienced with more databases than just SQL Server. (It's more than a crappy ODBC driver for a crappy language.)The point is that for a system you have paid $$$$$ over the years for multiple versions there's a lot of "magic" , "WTF?" and basic functionality that hasn't been fixed or tweaked. In fact a lot of these issues have been brought up by beginners and pros alike, only to be ignored or dismissed for years if not decades. And the point is that you can get around a lot of these issues by using software that work as well or better in many situations that you don't need to spend $$$$$ for.
Fair points and I agree. Far too much is made of adding new shiny knobs and not actually fixing things that need to be fixed.
July 6, 2015 at 9:17 am
Eric M Russell (7/6/2015)
The only compelling arguments presented, the ones that should be cringeworthy for the Marketing department at Microsoft, are that unlike SQL Server, PostgresSQL is cross-platform, and you can acquire non-handicapped production capable releases of PostgresSQL for free.
Maybe. I think the parts about much of the basic functionality that has issues or is broken hasn't been addressed for years. There are many common things we do that require more gyrations in SQL than are really necessary. The platform, IMHO, hasn't evolved to make my life much easier as a developer or administrator. It could do many things much, much better.
July 6, 2015 at 9:18 am
Eric M Russell (7/6/2015)
chrisn-585491 (7/6/2015)
The only compelling arguments presented, the ones that should be cringeworthy for the Marketing department at Microsoft, are that unlike SQL Server, PostgresSQL is cross-platform, and you can acquire non-handicapped production capable releases of PostgresSQL for free.
How about the fact that it's easier to maintain ETL applications with tests and source control than it is to train folks and support SSIS? Plus you don't have to buy additional licenses?
You don't have to use SSIS and can instead hand code your ETL in SQL Server, if that's what you feel most comfortable with. There are folks who successfully use SSIS every day; what they have is a pattern that works.
I'd agree with this. If you find SSIS difficult, use something else. However I also think MS should be improving things that are broken, like basic CSV support.
Without giving us the excuse that CSV isn't a standard.
July 6, 2015 at 9:19 am
There are folks who successfully use SSIS every day; what they have is a pattern that works.
Yes, but wouldn't they be more productive if Microsoft listened to the feedback and fixed some of the issues with it? Many of the pros are using Biml and BimlScript with SSIS instead of beating their heads against some of the SSIS funkyness.
Viewing 15 posts - 1 through 15 (of 43 total)
You must be logged in to reply to this topic. Login to reply