SQL Server Reviews

While I don't like SQL Server so much, the selection was for clients so we needed to utilize it. Of course, one thing is that as great with this and other Microsoft products is that it's quite well documented and there are also light versions available. If you need to do something, you can also try it somehow on your own computer and so on. 

If I'm helping a client to define what they need to have or what they need to do in a public sector procurement process quite often we cannot fix the database as it would be limiting the competition. That's why we never rule out the SQL Server; it should be included as an option at this level.

The solution is stable. 

I haven't had issues with sizing or scaling.

If it would be more powerful it would be pretty nice. The performance is not always the best. 

Whenever we were setting up the databases, there were some character problems that did not exist on some of the other solutions. However, the exact issues are hard to recall and list. I prefer Linux solutions. That said, when we began the previous project, Microsoft SQL Server was not available for Linux platforms yet.

Nowadays, it's my understanding that there are different versions. I haven't been checking if the current versions are supporting Transact-SQL and stuff like that. I remember that when we had the first Linux-based SQL Servers were introduced, they were, of course, a bit limited from the feature point of view. Whenever it is Unix or Linux or whatever platform, it's easier to manage them and to handle them whenever you are doing remote work. 

I'm not so big fan of the Microsoft platforms as a server. However, whenever it's needed then it's needed. If you are a consultant, you need to adjust your whole mindset to whatever it's needed.

I've used the solution, approximately, for several years. However, there have been gaps. There are different phases, however, I could count something like seven years where I was in an architect position in any project where this server was utilized. 

For the needs we had for the client it was sufficient. Whatever we needed to have - whether more server or more virtual server, the performance for the platform wasn't as good as I would like. I'm not entirely satisfied.

I haven't been utilizing the scale capabilities. I don't have a clear impression on that, however, for our purposes, we've never had an issue.

I've never dealt with technical support. The databases were handled by the service provider or service operator of our clients. We have a public sector client and they have their partner who is handling or is responsible for the platforms. Therefore, if we had a problem with the platform, the right bureaucratic way to go about getting a resolution is that we contact the service provider they have. They probably contact Microsoft. The process is bureaucratic.

I'm also familiar with other servers such as Oracle. While we must do as the client wants or needs, if I could choose, I would probably utilize databases like Oracle or open-source databases more often. It depends on the cases. That said, quite often I'm in a position where I cannot suggest the technology, so I use what the client requests.

We didn't pay anything for it as it was provided for our client by the provider. I cannot say about the enterprise licenses or anything. When we began the work and we needed it for our own machines, I prefer the solutions which are available, of course, as open-source or are free. And Microsoft had this express version of their database which we can utilize as well. In that sense, it is okay, however, of course, in general, I don't know.

I've been working for a client as a consultant so I'm helping them with deployments. With one client, we're using on-premises deployments. Our client has their own service provider or service operator so they have their own IT partner who is handling their databases. If I have understood it correctly, the databases were on-premises for our client, however, it's a bit complicated when you are having and dealing with large-scale public sector actors in Finland. There are plenty of kinds of players involved.

Whether or not I would recommend the solution depends. If you are utilizing some solutions where you need the Microsoft platform-based database, it's completely okay. And if you have, for example, the solutions where you have utilized Transact-SQL or whatever, it's okay. However, if you have this kind of situation where you can make your own choices freely, you have options. And if you're utilizing Java or C, et cetera, quite often the path or logic would go towards some of the databases on the Microsoft side.

There is no clear answer. Quite often when you begin to think about your solution or you think about what you are building, the database is the first thing you decide on. There are other factors too, such as a business case or if you're just building from scratch and so on and so on. I wouldn't like to say that I never would recommend it, however, if you are building everything from the scratch and you can make all the decisions, likely it is not the first option you have or I'd suggest. 

I'd rate the solution at an eight out of ten.

On-premises

We use SQL Server with Sage products.

It is used by our finance team and also human resources.

the database management tool is very easy to use and largely meets expectations

As SQL Server could not support the number of connections we desired, we were forced to go with Oracle. This is an area that needs to be improved.

for 04 Years now 

The solution could be more stable

The performance in terms of simultaneous connection must be reviewed.

We do not pay for technical support.

No

The initial setup is time-efficient and can be done independently.

There is no need for developers or managers to deploy and maintain the solution. One or two systems' administrators are sufficient for its deployment.

The deployment is on-premises. We installed the solution on a server and this on the Windows server. The user is provided an application for connecting to it.

great

The licensing involves a one-time fee.

We evaluated Oracle as an alternative.

For my part, SQL Server is aimed at small and medium-sized businesses, I would give it an eight out of ten.

I would not recommend it for a large company that has to support more than 40 simultaneous bi-directional connections to the database

On-premises

We primarily use the solution for recording transactions and information related to the reservation of a service. 

The product is very stable.

It offers very good documentation. When there are some little issues, it's always very easy to go into the documentation for troubleshooting purposes. There's just so much documentation on hand and a really great community around the product that is very helpful.

It's a very complete product.

We've found it to basically be pretty problem-free.

The integration with other products has always been quite good.

The security of the product has never given us any issues.

We're quite satisfied with the solution. There aren't any outstanding features we would like to add.

The interface could be updated to make it slightly more user-friendly.

We've been using the solution for more than ten years. It's been a while. It's been more than a decade at this point.

The solution is very stable. there are no bugs or glitches. It doesn't crash or freeze. it's excellent.

We haven't really scaled the solution all that much. At the moment, we have measured the scalability in a horizontal way. When we needed to have more installation and more capacity, we split the database into a different SQL Server instance.

In the future, we'll likely need to consider scalability more. We are also moving in the last two years, also to a different architecture from a monolithic to a more microservice architecture. Maybe the scalability can be more easily handled in the applications that are talking to each other and leaving the database out of the equation.

While end-users are hard to quantify, I can say that likely half a million users have come through our system for transactions.

In the near future, we will continue to use the solution. We might use it for the next four or five years, although it is hard to say.

We've always been able to rely on the fantastic documentation and great community around the product in order to troubleshoot problems. It's very easy to fix issues as they arise due to the public knowledge available to everyone.

We've mostly always used this solution. Last quarter, we moved a little bit to a NoSQL database. We have done a little experiment on Cassandra however, previously, it has always been on SQL Server.

We're considering moving away from the solution right now and trying something new. The owner of the company wants to experiment with other technologies and see what is out there, which is why there is talk of change. However, it's not a reflection on this product, which has been largely quite good.

The initial setup is not overly difficult. It's pretty straightforward. A company shouldn't have any issues with the process.

We have 12 technical people on our team that can handle the implementation.

The last version we used is 2015 if I'm not mistaken. We don't jump immediately to the latest version due to the fact that, usually, we look for stability. We make the move to the next version in case of some integration or limitation. We prefer not to move onto something that might have bugs or glitches that need to be patched. It's more secure for us that way. 

I'd recommend the solution to other companies.

I'd rate the solution at a ten out of ten. It's doing exactly what we need it to do. We've very happy with it.

On-premises

We use SQL Server to process a lot of data. We are using versions and 2015 and 2018.

We like the whole product and we use most of the features.

Indexing, as well as integration, are areas of this product that need improvement.

We have been using SQL Server for approximately five years.

It's a stable solution. Stability is one of the most valuable features.

It's somewhat scalable.

We don't have any issues with technical support.

We have used SQL Server from day one, along with OpenSQL. We used them both regularly.

We don't use Oracle often but we do have a few areas where it is used.

The initial setup was straightforward. 

We have experience and did find it to be challenging.

We do multiple deployments which require three or four teams.

The cost is high and because it's an expensive product, we are in the process of moving towards open-source solutions.

We have evaluated MongoDB and are in the process of transforming ourselves.

We will continue using SQL Server for some things but not everything. Most of our applications will be migrated to MongoDB and others.

I am not in the position to recommend SQL Server to anybody. Rather, I am more in the area of quality assurance. 

I would rate this solution a seven out of ten.

Hybrid Cloud

Mainly, I do infrastructure support. We do fine-tuning, information, configuration, higher-level availability, and replication. Also, single and clustering solutions - both kinds.

We do on-premises and cloud deployments. This is because some customers use Microsoft Azure, mainly in the financial sector, such as the Sri Lanka Government, who has many databases that cannot go on the cloud. The financial sector also works with on-prem databases.

I am mainly using the SQL Server from 2019. That's the latest version since last January while our customers are mainly using the 2016 and 2017 versions. This is because we are not providing the latest version. We are testing some bugs now. In terms of functionality, I think the 2017 version is better. I have not fully tested the 2019, so I cannot give a recommendation for it.

Its availability for a secured server is one of its most valuable features. Also its replication features are valuable- we can manage eight replicas. Their clustering and availability groups are also valuable.

They do not offer the SQL Server Management tool via the installation. It is a separate tool I use when I'm trying to configure the mirroring with SQL Server Mirroring. This is not supported and I'm getting some errors on the database mirroring. So sometimes I use the 2014 management console and the 2017 server for that. If the customer does not agree to that, I use a query for the database mirroring connections.

Additionally, I think some kind of machine learning related feature should be included. This is because technology is moving fast and all of the customers are getting it easier. So developers are making machine learning products. That's why they should include some kind of a machine learning feature here, too.

Which initial setup are you referring too? It has multiple solutions and installations, some of which are very simple. Clustering is very difficult to setup.

Setup time depends on the customer's environment, including database size, the number of databases, and the amount of data. Last week I did a PLC with two databases and one availability crew. It took two days because one day I did clustering. It can be done in one day but the customer provides another day for that.

Also, because the customers haven't kept some downtime, we request some kind of downtime for the primary server. So sometimes we plan downtime when we need some days for the complete environment.

I'm working with Microsoft solutions in Sri Lanka. We have a technical team for the DB side only - Microsoft SQL Servers, Azure platform, SQL servers. All of those have a security device. And as I mentioned, installation is per requirement. There is no need for a couple of engineers for that.

In terms of maintenance after the deployment, it also varies depending on the number of databases.

On a scale of one to ten, I would rate Microsoft MDS an eight. I'd give it an 8 and not a 10 because it lacks some features, such as machine learning.

Implementing solutions for controllers and project managers on their financial data for 10 years, and now using the Power BI Microsoft solution.

Implementing a unified, reliable database is one of the main improvements of departments whose business is to make decisions according their aggregated data. SQL Server, with the services it offers, has the full capability to manage this goal.

SSAS is the most interesting feature to organize the data and let the users play with it.

SSIS is also very powerful, but not always user-friendly. It requires you to build a solution around SSIS.

The reporting services of the solution (SSRS and now Power BI) are the less valuable items of the SQL Server suite. 

More than five years.

The primary use of SQL Server is to store and retrieve data.  If you go into the extra features that come with your license, you can also do reporting, analytics and ETL.

Everything is valuable. It is a relational database system which is critical for storing reporting data or any data that is highly relate-able. Plus your data is one of the most important assets in your company.  Might as well have a good system to protect it.

In a manufacturing system, storing test data in an Excel file has limitations in how much data can be stored at one time and how many people can manipulate the data at one time. Storing it in SQL Server allows you to store as much data as you have disk space for. It can be viewed and modified by multiple people at one time.

Setting up some of the more complex systems could be simpler. Things like service broker can be tricky to set up for the inexperienced.

More than five years.

Stability seems very good. I have not seen any issues with this.

I have not run into scalability issues. It feels very scalable.

I have not needed to contact technical support for this product

I did not use a previous solution. I have heard of other companies using Microsoft Access or Excel for similar problems. However, after hearing the headaches they have, I would not recommend those for large scale projects.

The initial setup was straightforward, but configuration post-install can be complex. Complexity comes from attempting to optimize it and implementing some of the new features that come in new versions.

We implemented it entirely in-house.  

Pricing and licensing is based on a per core and/or per-processor license. Try to keep these low, but keep it above four. (Four is the minimum number of cores.) If you are working mostly with OLTP, make sure your single thread CPU speeds are high.

We did not evaluate other options. The other options lacked support, lacked performance, or were too expensive.

If you don't have a DBA on site, hiring a consultant is recommended to help get things setup and configured. This will reduce headaches down the line.

Activity Monitor and Dynamic Management Views

After reviewing a client's Microsft SQL environment, I have been able to setup specifics alerts and jobs in SQL Server Management Studio (SSMS) to definitely show them where they are experiencing network latency, disk latency, memory pressure, etc., etc.  I have done this type of performance review for over 20 clients in the last 5 years

When reviewing SQL processes it would be great if all of the local processes on the SQL server were marshaled to a remote SSMS client.

I have been using Microsoft SQL Server since 6.0

WMI configuration

Setting up Microsoft SQL server performance alerts and jobs on a single server or in a Cluster is very straightforward. I typically start off looking at the following:

• Batch Request/Sec
• Buffer cache hit ratio < 96%
  
• CPU Utilization  > 80 % sustained
  
• Compilation/Sec
• Re-compilation/Sec
• Page Life Expectancy (PLE)
• User Connections
• Lock Waits / Sec: _Total
• Process Lock/Block By

My objectives are to provide a baseline to determine database growth pattern to ensure capacity planning, stability, bottlenecks, etc., etc.