SQL Server Reviews

We use it for warehouse data management, as well as for statistical reports. It facilitates tabling and query processing while supporting multiple database operations. 

The solution is valuable because it seamlessly extracts reports and enables the collection of information from different tables.

There is a lot of room for improvement when it comes to limited compatibility across the platform and restricted performance with massive data sets. Enhancing those two areas would significantly improve the operation. It is important to mention the licensing cost, as well. Optimization of the licensing options to fit different needs and businesses would be of great benefit. 

I have used this solution for ten years. 

It is a robust and stable solution. Its tracking record is reliable and it can handle large volumes of data.

SQL Server offers easy scalability, allowing databases to grow as the data and user base expand. 

Their customer service is great. When we faced certain issues, they solved them fast. There were no problems with communication.

Positive

The initial setup is easy, and integrating the system is okay. The only issue is regarding the customization of the business process of the organization, it might take some time. Ultimately, it depends on the client's specific needs.

SQL Server is an expensive solution. Their pricing structure and licensing options are not budget-friendly, so I believe it is an essential factor to consider when choosing the right product.

It proved to be a great fit for medium-sized enterprises, in terms of the variety of the tools it provides. For bigger projects and specific needs, there might be a need to employ different solutions such as Oracle, and ERP systems. But overall, it works great as a relationship database management system. I would rate it eight out of ten. 

It has all of our data. Our company sells contracts when you buy a car. We sell aftermarket insurance for the tyre, wheel, ding, dent, windshield, etc. When somebody buys a contract, we capture all of that data into a legacy database PostgreSQL, and my task is to incorporate that into our financial platform using T-SQL. So, I write queries, procedures, and views. I use SSIS, and I use SSRS. My job is to get the data into our financial system so that we can process claims, payments, cancellations, and refunds. 

In terms of its version, we're up-to-date. We have version 2019.

This is the heart of the whole company. SQL Server is where all of our financials are. It has all of our data.

I've been using SQL Server for 20 years, and there is nothing that it can't do. It is awesome.

When we are talking about event space architecture, scalability generally comes into play. For example, I might have a hundred thousand transactions a second, and then all of a sudden, I build something that everybody in the world wants. The next thing I know is that I have a million transactions a second. So, to be able to process the throughput, I'd have to scale up, and then when the holidays are over, I'm again down to a hundred thousand transactions, and I want to scale back down. SQL Server is not going to do that. In this way, it is not very scalable. One of the reasons why they want us to use Kafka is so that if we need to, we can do that, but our base program is on SQL Server. So, this is where we would use a Kafka event stack so that if I need more servers, I can just write a command, and I can have more consumers, more brokers, and more producers, and when the holiday season is over, it scales right back down again. SQL Server is not going to do that.

I have been using this solution for 20 years.

We do clustering. If one SQL Server goes down, it automatically goes to another one.

I don't ever need tech support. If it breaks, I can just rebuild it.

They're now using a different database for contracting called Road Runner. I don't know what that is, and how it stores data. I don't know anything about it. 

There is also Postgres. I like SQL Server more than Postgres. That's only because I know SQL Server. I don't know Postgres as well. So, I can't say which one is better because I don't have the same amount of experience in both.

I can bring up a SQL Server in an hour or so and set it up.

In terms of maintenance, the number of people required depends on the need. 
We have a team of DBAs, developers, and UA analysts. We probably have 40 people in our IT area who are maintaining our solution. I'm just the developer. I'm the guy who makes the magic happen, but without other people collecting the information that I need to make the magic happen, I'm stuck. Without the guy who is an expert in permissions, partitioning, and performance tuning, I'm stuck. So, it's definitely a team effort. You can do it all, but you don't want to do it all because then you're running your head off, and you don't really get good at anything. It would be a jack of all trades, master of none type of scenario.

You will seldom find a database that was designed correctly. Just because you got a poor-quality database doesn't mean that you're going to get a better database anywhere else. You rarely get to build a thing on your own. Usually, you inherit somebody else's stuff. So, the challenging thing is working with what you have while trying to implement a better solution. My only advice is to be patient.

I would rate it a nine out of 10. I wouldn't give anything a 10 because I don't have that kind of knowledge, but right now, it does what I need it to do.

We use SQL Server to host our ERP system. It serves both as the underlying database and server application software. This database solution handles all our ERP calls.

We use SQL Server to support Business Intelligence. It also connects with Power BI. We create all our views and datasets in SQL, specifically for Power BI. Previously, we used Tableau but transitioned to Power BI for all our analytics needs.

SQL Server provides access to audio information and audio tables. You can customize and create views. The ability to customize and upload these services is uncertain when migrating, but SQL in a local environment or Azure seems suitable for now. The ability to see tables, reviews, and custom script options is good.

The upgrades are unstable.

I have been using SQL Server for several years.

I rate the solution’s stability an eight out of ten.

I rate the solution’s scalability a seven out of ten.

The support is pretty good. We have never had to reach out to Microsoft for issues. It is a pretty solid application.

The initial setup is straightforward. You need to install technical agents and create databases.

We use Active Directory authentication. If you have access to the database, it's secure. Not everyone with access to the database can access it. Only our IT staff or those who require access have permission. It does offer a high level of control and security.

We have a small team. We could explore Azure Virtual Desktop or engage with local partners if we need additional technical knowledge. We employ a cloud gateway, enabling our SQL database to be somewhat cloud-based. This facilitates integration with various cloud applications, such as the Power Platform. We use Power Apps and Power Automate, allowing us to connect to our database in adaptable and scalable ways.

I recommend the solution if it meets your requirements.

Overall, I rate the solution an 8 out of 10.

We use the solution as the backend for the application.

SQL Server is a backend for software products that our company writes and distributes.

SQL Server is easy to use, but there is a great deal of complexity that you can dive into to use it to its best. Also, it integrates well with other platforms.

SQL Server should make the pricing simpler. It should add simplified load-balancing features.

I have been using SQL Server for 24 years.

There's a reporting database feature in SQL Server, but running multiple instances on the same box would be beneficial. That's one limitation we've encountered. Many of our customers utilize a hosting provider that offers multi-tenant SQL Servers, but we cannot implement a multi-tenant reporting database. 

The solution’s scalability is good.

There are a lot of different deployment options. The default options will work pretty well. We have to change a few things for our setup. Deployment is not at all long. It takes a couple of minutes. It took a long time for the first time because I had to go back and redo it and change the configuration, but it runs pretty smoothly now.

The deployment process follows: mount the ISO and run a script. That script retrieves some entries from a table and creates several instances based on that table using active directory SQL Server accounts, which is an out-of-the-box option. There are a lot of features that you can add to the setup to make it quieter. We've automated it so we can spin up an instance as needed for development processes.

Deployment was done in-house.

Overall, I rate the solution a 9 out of 10.

We use the solution for data quality purposes like checking, testing, and writing its cases using data validity and quality measurements.

The valuable features are Excel integration, writing a query in SQL Server, exporting the data, and copying the data.

When transferring data from the SQL Server to Excel, the data types are not copied correctly. This issue might be associated with the formatting of the data types. Specifically, the data types for dates and timestamps have not been copied correctly.

In SQL, as with other databases, abbreviations are commonly used to simplify tasks such as writing queries or commands.

I have been using SQL Server for 3 years. We are using V18.0 of the solution.

The product is stable. The community is big.

I rate the solution's stability a ten out of ten.

The data warehouse engine should be scalable.  It's not scalable. We use it every single day.

I rate the solution's scalability a three out of ten.

I have used Oracle Server.

The initial setup is straightforward. The connection to the database is not straightforward. There are many ways to connect to the database. It may be tricky to choose which way to connect.

I rate it seven or eight out of ten, where one is difficult and ten is easy.

The solution is good for a transaction database, but its performance is not very good. One or two persons are needed to maintain an SQL server.

I recommend the solution.

Overall, I rate the solution a seven out of ten.

We do data warehousing on it. We have databases on it. A lot of our applications use it for transactions and data.

We're using version 2019. We're trying to migrate to 2021 because 2023 is not yet that stable.

It works fine in terms of performance and stability.

I would like Microsoft to evolve SQL Server because stateful databases dying are in a way. We would like to find out if it can absorb Hadoop and other similar things. They should make it useful for data mining. Data is evolving forever, and how we store it is also changing constantly. So, SQL Server also needs to change.

I have been using this solution for two decades.

It works fine. There are no issues.

It is scalable. There are a lot of users. There are over 300 applications using this solution. Each application has its own users. In the technical team, there are about 13 people working with it.

I logged a ticket recently when I had an issue with the data manager. Their support wasn't that bad. I would rate them an eight out of 10.

I've used different solutions. There are times when I use Db2, and there are times when I use Oracle Database. Oracle beats SQL Server when it comes to procedures and process optimization.

The initial setup is easy. It takes 30 minutes at the most. What limits you is just your infrastructure in terms of:

• Do you have enough room on those servers to process that stuff?
• Do you have enough RAM resources?
• Do you have enough storage?
  

I can do it by myself.

It is annual.

I would recommend it to other users. I would rate it a nine out of 10.

In my data warehousing project, I use SQL Server alongside Power BI. SQL Server serves as the data storage solution, while Power BI is used for data visualization.

The most valuable features for database management in SQL Server are SQL Server Management Studio and Visual Studio Code with its administration capabilities.

Improvement in SQL Server should focus on lowering the high cost, especially for environments requiring extensive CPU and memory usage like data warehousing. While existing features are great, affordability is a significant concern, particularly for enterprise licenses. Additionally, enhancements in managing availability groups and clustering could be beneficial.

I have been working with SQL Server for 20 years.

I would rate the stability of the solution as a nine out of ten.

SQL Server is highly scalable, but the scalability comes with a price tag. Additionally, for on-premise deployments, hardware purchase is necessary, which can be a limiting factor. I would rate the scalability of the solution as an eight out of ten. We have approximately 500 users at our company.

My experience with SQL Server's customer support has been positive in the past, but recently, I have noticed a decline in responsiveness, and now I would rate them as an eight out of ten instead of a perfect ten. While I used to receive prompt answers to my inquiries, I have had a question pending for several weeks now without a resolution. It seems that Microsoft's focus on Azure may be impacting their support for on-premise solutions like SQL Server.

Positive

The initial setup of SQL Server is straightforward and user-friendly and I would rate it at around an eight out of ten for ease of use. While the basic setup is simple, additional considerations for security may require some tweaking. 

Deploying a SQL Server for testing purposes typically takes around ten minutes, while for production, it can take an entire day due to the additional tweaking required for optimal performance and security.

SQL Server is generally more expensive than other solutions. I would rate the price of the enterprise version of SQL Server as a ten out of ten for being very expensive compared to the standard version. The enterprise version costs approximately 20 times more than the standard version.

We use SQL Server Availability Groups for high availability. It supports our requirements well and is preferred over cluster solutions for its effectiveness.

SQL Server offers advanced security features like data masking, which allows users to restrict access to specific columns, enhancing data privacy and control. This capability is particularly useful for protecting sensitive information from even database administrators.

SQL Server is the primary technology we use, tightly integrated with our existing IT infrastructure and applications. We rely on Microsoft products for seamless compatibility and avoid unnecessary complexity by sticking to a single vendor ecosystem.

My recommendation for using SQL Server is that it is a stable and versatile option with a lot of capabilities. However, there are cheaper alternatives available on the internet that offer similar performance. It is essential to consider whether the cost difference justifies the added performance of SQL Server, especially when cheaper options can achieve comparable results with slightly slower hardware.

Overall, I would rate SQL Server as an eight out of ten.

Out of all the tools in the complete SQL Server package, I'm mainly using Toolbox and SQL Profiler because I'm using SSIS packets, so we're using job scheduling a lot. And sometimes we are creating the SSIS packages, so I'm using SQL Server for MSD for maintenance purposes. SQL Server is quite user-friendly. I have experience with Oracle and PostgreSQL, so out of three, I like SQL Server a lot.

They could increase the intelligence of SQL Server. That would be good for us.  There are some good intelligent features in SQL Server. However, they need to increase the intelligence because people switching to SQL Server from other solutions are not so familiar with it. I've been working with SQL Server for the last six years, but people are coming from MySQL or Oracle, so it will take one or two months to adjust. Still, they could add some intelligent tools to convert Oracle into SQL Server something like that. 

And sometimes when I'm writing a function, there is already a predefined structure available. So if they defined their structure more precisely, that would be good for us. And the last thing I would like to add is that SQL Server should handle queries more like Oracle does. For example, you submit a query in Oracle, and the whole table comes up. In SQL Server, you go to the table, right-click, and it lets you see the first 200 rows. Then on top of that, you can add 200 more rows.

So in place of those 200 rows, if I can update all my table records or search my table record without a new search query, it'll be very beneficial. That functionality exists in Oracle, but this feature is not available everywhere in SQL Server. So if SQL Server had the feature, it'd be great because SQL Server is lacking only on this point. For example, one of my clients is a semi-technical person, so I have to train them to file a query in SQL. And they say that Oracle is much better. Say, for example, that I wanted to query a particular employee from a list of all staff. So the query output comes, and they can directly filter out the data by just applying the filter. They don't have to use the drop-down menu and search for all the employees with a given name. 

I've been using SQL Server for the last six years. I'm working with SSIS, SSRS, or MDS. These tools are part of SQL Server, and the back-end queries are developed in SQL Server. 

SQL Server is stable. SQL Server has crashed only two times in six years, but it wasn't a major system error. 

It may be a licensing issue, but sometimes its operating speed becomes slow if we have multiple users. It's lacking some performance, but it's acceptable because we have a heavy load. And I would like to add that we're running SQL Server and SSIS at the same time. So while I've found that SQL Server is quite fast, SSIS is a part of SQL Server. It is just for data testing in India. But if a person knows SSIS, then they usually have very little knowledge about SQL and vice versa.

I know both of them. I found that maybe it's a bad habit, but I'm using SSIS packages. And in the SSIS package, I'm using Toolbox from SQL Server to improve the latency. Implementing both together takes a little time. And one more point is data handling. I am just forwarding the error names, and there are multiple errors in the SQL Server tool, but what if a person comes to work under me and has only one or two years of experience?  Sometimes it might be difficult for them to understand what the errors mean. For example, when joining data, it's easy to implement the inner joint. In the inner joint, there are two columns, so when there's an output error, someone who is inexperienced with SQL Server might not understand. Error messages should be a little more precise and defined, so it's easy to understand.

Setting up an individual SQL Server is pretty straightforward, but when you are implementing multiple tools, it's more complicated. In terms of maintenance, for the DBA part, there are two based in my company because I am on a master device, so they don't allow me to maintain the server part. So one person is from South Korea, and the other is from China. They are handling my SQL Server. So maybe there are multiple teams, but I am contacting these two guys, the DBA. And I'm MDS, so I'm a single person. There are two people on my team, and I have one junior staff member. So I have a three-person team, and there are two DBA sites because I'm discussing my master team. I am deployed on the business side, and there are more than 80 people who are end-users of SQL.

If you're using SQL Server along with SSIS and SSRS tools, it works pretty smoothly and all. When working with Oracle SQL, PostgreSQL, MySQL, etc, there are a few problems with the connection.

Overall, SQL Server is good, but sometimes, optimization becomes a little bit tricky when you're using SQL Servers in place of Oracle. For example, while I was implementing two queries one time, the SQL Server gave me the wrong results. This wasn't because of their internal modules. So there may have been some missing data, but SQL Server failed to identify those issues. SQL Server needs to improve there.

For example, say there is a line with a value of 136 or 137. The second value is a space, and the third value is null. And the last one is space. So a space means this is also null. So you are comparing these four values, and if you don't have any idea about data, it's a little problematic. So cases like this, we can deal with such queries using syntax, but if a person has no idea how to deal with this, they'll face an issue.

Here's another example. Say there's a team query that means we are erasing data from the teams, and some people are just analyzing the string. So I see data from it, which means the calling system is there. In the calling system, we receive the data to call anyone, and that type of wire call setup is there. So I am receiving a full-text format from the file I have to upload in the SSIS package. And some cells have a null value. It's a text file, so you can understand there are blanks in some places. I don't know the file type, so I am just trying to dump it into our SQL Server. But when I have time to get to that table, I realize that some values are null, space, and blank. So these four values make problems for me.

I rate SQL Server nine out of 10. I would recommend SQL Server to anyone because you can use cloud-based services, so it's very beneficial. If you install SQL Server on-premise and on the Azure cloud, it is much more advantageous for you.