SQL Server to the rescue
April 22, 2016

SQL Server to the rescue

Andy Erickson | TrustRadius Reviewer
Score 7 out of 10
Vetted Review
Verified User

Overall Satisfaction with Microsoft SQL Server

Our company uses Microsoft SQL Server for much of our database storage needs. In the energy section, we use SQL Server to store sample data, generate reports and spreadsheets, as well as internal reporting and data manipulation.
  • SQL Server is a whole package that usually connects well with other Microsoft products.
  • SQL Server has a large community of users for tips and advice on SQL programming.
  • SQL Server works fairly seamlessly with Power BI, Power Query.
  • One glaring example is importing spreadsheets through SSIS, SQL Server only seems to sample the first few rows and generates errors if larger text cells are further down the rows.
  • SQL Server tends to be a bit more touchy with database object names than MySQL.
  • The good - SQL Server has a lot of ways to get at the data, the bad - finding particular settings is often buried in dialogs.
  • Since our company is mostly a 'Microsoft shop' it is easier to deploy SQL Server projects than any other solution.
  • Licensing issues still thwart my efforts to implement quick web tools with SQL Server.
  • Applying Power BI is a great technique to give project managers a view to the data fairly quickly and relatively seamlessly.
  • Drag and drop coding speeds up my queries, there are lots of built in query strategies that make quick work of code production.
  • Import from Excel with SSIS has consumed large quantities of my time with mixed results.

SQL Server is a full feature robust platform with relatively mature coding standards. Interactivity with other Microsoft products enhances my workflow with minimal installation headaches.

In contrast, easier licensing for MySQL and SQLite gives them a definite advantage, especially coding up webpages to deploy on the internet with PHP.

I use SQL server because I can get help from others at the company and support from IT. We have multiple SQL servers to deploy data as well as a copy on my local machine for testing. If I was doing data with millions of rows, SQL Server would be the preferred choice for a RDMS.

My investigation of Couchbase leads me to believe it would be extremely useful for temporary data storage, and deployment without extensive database normalization involved with RDMS.

I appreciate the tools SQL server management studio and SQL Server Data tools provide to manipulate data both in and out of the databases.

Microsoft SQL Server is great for interaction with other Microsoft products, it tends to be the elephant in the room, you can't miss it. MySQL can be a much more compact installation and requires fewer licensing issues to deploy a solution. Setting up a quick database and querying the data with Power BI is becoming much simpler as these products mature. As long as you already have SQL Server installed somewhere, that is. Importing data into SQL Server from Excel is pretty straight forward and it automatically sets up fields fairly well.

Using Microsoft SQL Server

SQL Server mostly 'just works' or generates error messages to help you sort out the trouble. You can usually count on the product to get the job done and keep an eye on your potential mistakes. Interaction with other Microsoft products makes operating as a Windows user pretty straight forward. Digging through the multitude of dialogs and wizards can be a pain, but the answer is usually there somewhere.
ProsCons
Like to use
Technical support not required
Well integrated
Feel confident using
Unnecessarily complex
Slow to learn
Lots to learn
  • Simple data imports work well.
  • Drag and drop queries and selecting into new query techniques allow you to generate queries with less typing.
  • Accessing stored procedures is nicely organized by the 'folder tree'.
  • Importing through SSIS can be a real pain, my associates indicate that this is not usually the best approach.
  • Debugging SSIS errors can be difficult due to the number of things that can go wrong.
  • Field investigation/prefilling from data sources is often plagued with incorrect choices - requiring manual intervention.
  • Accessing import fields through levels of 'wizard dialogs' can be confusing.