SQL Server Reviews

We have a few transitional systems in our large company that we maintain with Microsoft SQL Server.

SQL Server is similar to other Microsoft products, such as BI, they are easy to use. You do not need to have an expensive BD to maintain them. All the useful intuitive features you find in Microsoft solutions you will find in SQL Server.

I have used SQL Server within the past 12 months.

SQL Server is stable. However, every product has limitations. It is stable for a certain amount of workload. Beyond the capabilities of this solution, you will need other data solutions, such as Oracle. A solution that is more secure.

Since this is a relational order system, scalability has a limit. If your system is very big, you need bigger servers and you have to spend more money. We scale a system up to a certain level, and then we move or shift data to the warehouse, which is NoSQL. We then do not have any bottleneck in scaling. For using this technique we are happy with it.

It is hard to tell or count how much data we are using because being one of the leading companies in Bangladesh, we have many teams who work on it. Different teams work on many different technologies.

We have not had an issue with the scalability SQL Server.

For databases, we have used a lot of data tests with other solutions, such as Oracle. We have used all Oracle data, Postgres, and a few others.

The initial setup is very straightforward. You do not have to worry about the management of the SQL Server instance.

To scale the solution there are additional costs.

I rate SQL Server an eight out of ten.

We use the product as a database, a data tool for everything. 

SQL Server, as a database, is great.

When it comes to the governmental sector, it is easily dealt with and can handle a big load of data. Specifically, after they added the capability of building a big data cluster from the SQL Server itself it's been great. 

If it was a database developer who was working with it or database admin, it provides a lot of tools and potential utilization that helps in doing the work in the right way.

Stability-wise, it's stable. 

If we want to expand to other servers and create an extra node, it's expandable. If you want to connect it with another, let's say, cloud node, it's also expandable with the cloud node. 

Security-wise, it provides most of the required security aspects in the market suchg as hashing, or encrypting, or hiding some data in tables (according to privileges and tools of the users). That can be done throughout it easily. 

It's an out-of-the-box solution. Lately, after they created the SQL Azure, if you use the Azure SQL Explorer, or SQL Server Management Studio, both of them can connect to the same database easily. It's natively built on the same core.

In my experience, while working with multiple sectors, such as banking, services, et cetera, there are some limitations for some sectors when dealing with the data.

It would be great if we were able to run it on multiple operating systems and not only stick with Windows. 

I've been using the solution for five or maybe six years. It's been a while. 

The stability is great. there are no bugs or glitches. It doesn't crash or freeze. Its performance is reliable. 

It's very easy to scale the solution in multiple ways. If a company needs to expand, it can do so easily.

I can't say it is easy to deploy as it depends on the admin, however, it is doable. Most of the databases, in general, require configuration. Therefore, if the admin knows what he's doing, then it's super easy.

A full deployment, depending on what is needed, might take anywhere from 15 to 30 minutes. It's fast.

I can't speak to the pricing. I don't have any information on that.

It's my understanding that we pay for licensing on a yearly basis. 

There is also another added product they created, called Synapse, Azure Synapse Analytics. Both of them are similar to Microsoft PowerBI on-prem with SQL Server on-prem.

I would rate the solution at an eight out of ten. There are other competitors that are also doing a very good job as well.

This client, specifically, is using it for Dynamics NAV. I don't know what they're calling it today. Microsoft changes the names all the time, 365 NAV Dynamics. This is ridiculous. We're using it for that, and we have more of a niche CRM database called Tour de Force. It's owned by a company called White Cup. They own a bunch of companies, and it sits on Microsoft SQL, as well.

One of the things I most like about SQL Server is the log shipping piece.

I have another client who uses GP, and they use Power BI to take the data out of the back end. I'm doing an IT assessment there, so I'm not really involved in that specifically, other than the fact this person has too many rights.

I have an auditing background, and I spent 25 years doing IT auditing as well. I understand I'm not a programmer, but I've been involved with enough of them. The log shipping really is one of the greatest features. It is not the only database you can do it in, but that was one of the better features of it because I am a backup nut. We use Veeam Backup and Replication to a local mass storage, but then we fully replicate everything in Veeam to another site with the exact same server set up at our other location. But I wasn't satisfied with that from a disaster recovery point of view. My IT company was, but I was not. I said, "I want to do SQL log shipping. I want to do an SQL backup and SQL log shipping and move it to Azure in the cloud," which is what we do every day. We have an hour by hour backup, in addition to our multiple nightly backups and our replication to our other site, and we've had to use it and it worked. This is a great feature.

Somebody who knows it would easily say, "No problem," because we set up our log shipping in about three hours. We sometimes have challenges with it in terms of timing, of getting it out, backing it up, and sending it to the cloud. There are always the glitches, but I get a daily report on what's going on. Around 30 backup jobs are running at all times, because it is a big company. It's a 200 person company.

In the next releases, I would only like more enhanced backups and more restore points. Data backup and cyber protection are the number one things everybody should be thinking about now. They may not be, but they should be. We're going to go to the Azure environment because that really is a duplicate of the on-premise environment, just somewhere else.

I would say that I have been directly involved in the ERP world for as long as I can remember, but SQL really didn't appear on my radar until the mid-90s. I know that early GP was out there. I believe it was on an earlier version of SQL. I use it heavily now because I'm the CIO. I'm a consultant, but I'm a CIO of a client for almost nine years, where we have two major databases sitting on SQL.

So I have always been involved in a Microsoft environment.

We are always deploying the latest version. I have multiple clients with SQL and Oracle. But my big client is always up to date.

Whether it is deployed on the cloud or on premises depends on the client. My big client is on-premise and we have a two year plan to move to the cloud.

In terms of scalability, I haven't seen any problems with it. We have 120 users. Every once in a while we get a record lock in our data. It's very rare though. Once every six months somebody hits the same record and same night. It's very rare. You go out for a minute, come back in, and it's over.

I don't have any Fortune 5,000, Fortune 2000, or Fortune 1000 companies. According to the governmental definition, they're small, they're SMB, but my big client is 200 million. To me, that's a lot of money-

But in the eyes of the government, they're still a medium company. I have clients with 1,000 people, but they're only a $50 million company. Those are not for profits. They're paying people 10 bucks an hour. It's very hard to categorize that if you're looking at it from a business perspective versus a technical perspective. I have a client with 1,000 people with 82 sites. So that's a technical challenge, but they don't have the same kind of money as the other people do.

It's a different way to categorize it.

Calling Microsoft is like calling Verizon. I wouldn't do that. I have a middleman that I work with. It's easier because they have more clout than do. I know that.

This client, the big client I've been talking about, had some ancient DOS system from the 70s when I got there in 2012. They had no data dictionary note. I think it was running on an early version of Unix on a Compaq machine. When I got there, it was 15 years old. The thing was still running until six months ago. You can't believe it. This thing wouldn't die. I tried to make it die multiple times, but we converted from that system onto Dynamics NAV.

It's a two year undertaking. The SQL was stable all the time, never had a problem with it.

In terms of the initial setup, you probably need to know what you're doing. I haven't seen any real laypeople get into the tables. I know it's possible to learn. Things like Power BI have made it easier, but if you don't know what the tables are you have to be a very methodical person to be able to do that stuff. We use a company called ArcherPoint for dynamics. They're one of the largest dynamics dealers in the country, and they have their stuff together. This woman I use there knows her stuff. She knows SQL very well, and my IT company also has a senior guy who they often talk to, and it always seems pretty straightforward, whatever they do. It's never a big install.

Usually a few hours and it's over.

This client has money, so I never hear any complaints. It seems reasonable to me. I think the biggest problem that Microsoft had back in the early 2000s was that the pricing of SQL was a nightmare. You could call five Microsoft people at Microsoft, and you'd get five different prices. Microsoft has a problem. Well, they have lots of problems. They characterize themselves as perfect.

From 40 years ago, I already knew well in advance of the clients that there is a security hole. I'm looking at Business Central, and somebody who has a global super admin of the tenant can get into the client's accounting system if they have full rights to their 365 email system. That's a big security gap. Their IT company shouldn't be in their financial system. Why would that be? I came up with the idea after talking to five different Microsoft people to just buy another tenant that they don't have access to and they said, "Oh, that works."

SQL Server is a good mainstream application that has been around for quite some time, and I like when things are around for a while. I don't like to be the first kid on the block. I remember when Power BI first came out. I waited a year and a half to use it.

The big thing for NAV was to get reports. We still use it, but we mostly abandoned it. It's really not working as well as I would've liked. And that reads SQL tables. While that was great, you had to trust the person who wrote it, that it would include all the data you needed. There's a big trust. We often found lots of problems with it, so we decided to just program all these reports inside the application. That worked really well. The thing I don't like is, I know a lot of people don't know about the backend security of SQL. They think others cannot get into their system and I tell them they can, they have the SA password. People are shocked. That's a hole that they should plug.

They should plug that and make that more apparent to people. When I did auditing, most clients had SQL based applications, and we'd always say, "Who's got the SA password," and they'd say, "What are you talking about?" Then we would tell them, and there is all this SQL injection stuff that used to happen. I haven't heard of any hacking through the back end in a while. Because you're talking about cybersecurity being so important now, people can hack in and get into the back end, although 99% of cyber is ransomware through email.

The risk is probably still low, but I try to close up all the gaps if I can. Clients don't know about this stuff. They don't even know enough to ask. I find a lot of IT people don't even think about stuff like that.

I'll ask a client if they back up their data and how often. If they talk to their IT guy? If they say, "Once a night," I ask, "Okay, what if it was the middle of the day and you go down? You lose all your data." I ask if they have ever heard of SQL log shipping. They start stuttering because they don't know how to set it up.

It would be great if Microsoft was more up-front about how to do that stuff. It's a great feature.

On a scale of one to ten, I would probably give SQL Server a nine. I don't give anybody a perfect score, certainly not in the technology world. Oracle is out there. NetSuite is just giving it away. You have a lot of other applications not running on SQL, like Intacct, who are creating proprietary, non-Microsoft things to come against what Microsoft is offering like interoperability with different applications. They are really pushing a different environment. I think Microsoft is going to win, but Sage is not a small company.

We have all these big titans fighting each other.

We use Microsoft SQL Server as our main database. We implement our solutions to the client site, providing the machines and the SQL Server license depending on their requirements.

The SQL Server is being deployed on-prem. Most of our clients are from the pharmaceutical industry. If there is a physical database, they want a self-hosted server always on-premises. However, the market is slowly adapting to cloud servers. Scalability and security have increased, so now people are going with cloud servers like AWS, Azure, and Google Cloud. Most of our clients are hosted on-premises and they have their own server, so we don't go with any cloud server. However, we are planning to move ahead with cloud servers for many of our clients.

The replication feature, user interface, reporting services, and notification services are really good. They are providing SQL Profiler and sqlcmd as their integrated software, so we don't find it difficult to integrate any of our third-party applications with MS SQL because all of them support MS SQL very clearly. As a part of optimization, it is good for processing huge amounts of data.

Performance could be improved. There could be more support toward PHP-based websites and toward providing direct plugins for connections, and the related services or application services could be improved. The user interface could be improved so that someone with less knowledge could easily integrate and use that particular module software.

In the next release, I would like to see a separate tool provided to schedule backup or implement backup solutions on any of the servers that Microsoft has installed. This would be a small utility which I could open and point out the backup parts as well as the type of backup I want. Once I decide the time and set it up, it should be able to connect everything and then accordingly run that back up on an automated basis. 

Right now, people are making their own utilities to do that same thing, but it would be helpful if we could get it directly from Microsoft. Apart from this, it would be helpful to have small plugins or API-based connections, which could be used for integrating MS SQL with different platforms.

I have been using MS SQL Server for 11 years, from the very first day of my job. MS SQL is widely used because its compatibility is good, especially with the .NET Framework because most are Microsoft products. The integration and the response are good, especially if you have huge amounts of data.

Now in the market, there are NoSQL options like MongoDB and Hadoop. Previously, there were pretty much three main databases: MS SQL, Oracle, and MySQL. MySQL was mostly used for small software, but many enterprise software were using MySQL because of the configuration, the compatibility, and the performance.

If you're using platforms like ASP.NET and C#, then you will want MS SQL Server because enterprise-level Microsoft provides many features like analytics services, reporting services, notification services, and now they're providing Microsoft Azure integration services.

MS SQL is very stable. However, the corruption of databases needs to be handled more accurately. If I'm using MS SQL Server and my server accidentally restarts or one of my machines restarts accidentally, then usually the MDB or the MDF file is corrupted. That corruption of files should be handled more efficiently because the client loses most of the data. Of course, the backup plan should be more efficient, putting less load on the server. That needs to be improved and more optimized.

Scalability is good. We have worked on almost 25 loads of data and 35 loads of records in a month. Most were working fine, but after time the process slows down a bit. In MS SQL, the initial 70% would work fine, but when the database starts and the load gets full, it causes slow processing. But considering the cost, features, and compatibility with Microsoft, it's a very stable database.

I have not been in a situation where I required help directly from MS SQL Server because we have our own service team that handles those issues.

Initial setup was a bit complex, but it's doable because it has improved a lot. Previously, it was very hard to install MS SQL. If I had the 2016 version already installed, it allowed me to install 2018 as well. The report features were distributed between two services, and that's where it causes problems.

We implement our solutions to the client site.

For personal websites and personal software that isn't used by more than 100 people, I will always go for MySQL for two reasons: MySQL is free and the enterprise is very low in cost.

Oracle Enterprise is another option, but the cost is high when you consider that MySQL is free.

I would rate this solution 7 out of 10. 

Microsoft's modules are really good. The syntax used for running the query is really easy. Their options for concurrency and locking are good, as well as their prices. They have created separate models such as distribution services and replication services. They are really good options so that if I want to take that service, I pay for it. If I don't want to, then I don't install it and I don't use it. Modular installation is something that I like about MS SQL Server.

If you have a lot of knowledge about MS SQL Server, you will be able to handle huge amounts of data very efficiently. However, you should make sure that you have regular backup protection. 

The servers which you have to purchase for installing, implementing, or managing MS SQL Server need to be optimized in a better way so that you get optimized performance from MS SQL.

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. 

There are many applications between Microsoft and SQL. Most are in the legacy direction, but some are more modern databases with those application requirements. We have used it for multi-purposes such as back-office products applications and cloud office environments.

The solution is easy to use, has rich feature sets, and is business-oriented. 

They could improve the solution by allowing more portability between on-premise and the cloud.

More improvements can be brought around hyper-threading. Like we see in work engines of hyper-threading. It is very complex in terms of the way they do it. If it was via CPU or something else, it would be much easier.

In a future release, they could improve by expanding their form base capabilities.

I have been using the solution for a couple of years.

I have found the solution to be very stable.

The solution is scalable.

The support is good for the solution.

We used Oracle and DB2 in the past.

Initially, the installation took a while. We have started deploying configurations that are now standardized. We have automated it, but it can still be problematic. For the most part, the installation is now quite easy. Additionally, The way they have many configurable parameters that influence performance is in a way problematic.

We did the deployment of the solution and we have a team of 15 people doing the deployment and maintenance.

The licenses are really expensive. Their licensing model should be more simplistic.

I would recommend this solution to others and we plan to keep using it in the future.

I rate SQL Server a nine out of ten.

The product enables us to grant access to users. The product is easy to use.

The pricing could be better.

I have been using the solution for about four years.

We did not have any issues with stability. The tool is stable.

The tool is scalable. Four other users have access to the server. We are not planning to increase the usage.

The setup is straightforward. The deployment does not take very long.

We did not use an integrator for the deployment. Our in-house team has been able to deploy the tool well.

We pay a yearly licensing fee.

I recommend the solution to others. The solution is straightforward to work with. Overall, I rate the product a nine out of ten.

SQL Server is used to establish secure storage and protect databases from potential vulnerabilities, including those originating from Slack.

The most valuable aspect is the ability to use jobs and various functions to accomplish specific tasks, which cannot be achieved with standard procedures alone. This allows for a combination of features and functionalities to be employed.

I have experience working with SQL Server 2016 and older versions, including handling JSON data. Initially, I found the JSON capabilities to be less helpful, but over time, they have greatly improved. 

SQL Server now offers extensive capabilities for working with various forms of data, particularly when communicating with text, such as in JSON format. 

I particularly prefer working with these features on Azure, as it provides numerous possibilities, especially in the field of business intelligence (BI). Additionally, the serverless platform offered by Azure is highly beneficial and makes tasks easier to manage.

I have not seen significant returns thus far, but I am eager to enhance my experience by transitioning to work in Azure. This shift to Azure is something I am motivated to improve upon.

I have been working with SQL Server since 2018.

We have not had any issues with the stability of SQL Server.

Scalability is dependent on memory.

The matter at hand pertains to whether we are discussing an issue in general or specifically in the context of on-premises environments. However, it is clear that memory and capacity are significant factors in both scenarios. 

Proper management of memory and capacity is essential to ensure smooth system operation and prevent any performance or stability issues. 

As a result, it is essential to handle these issues completely and appropriately in order to meet the system's requirements.

I have not contacted technical support.

The installation process is not complex, but it requires attention to detail in terms of selecting the necessary services and configuring the Cisco server. 

This ensures a proper setup and a tangible model for effective management. While it may not be complicated, it is important to choose the appropriate features during installation. 

Working with ID was not my primary focus; however, I have had the opportunity to work with it for several companies.

It can take an hour to an hour and a half to deploy.

Maintaining it is more challenging than the initial setup. One of the main concerns is ensuring sufficient memory allocation. The default capacity is typically set around sixty, but it can be increased if needed. If there is insufficient memory, it can lead to server downtime and cancellation of transactions, as exceeding the memory limit poses a risk. Therefore, it becomes crucial to address this issue by allocating more memory resources. Additionally, backups and restores play a significant role in ensuring data safety and recovery in case of any issues.

For a brief period, approximately one year before 2018, I had experience working with the open-source version of SQL Server. During that time, I found SQL Server to be the preferred choice, in my opinion.

I developed an application for specific purposes related to McDonough. Using Microsoft SQL Server, I constructed the entire database and implemented supporting stored procedures. This application was commissioned by the European Union to enhance government institutions and similar entities.

Additionally, I worked on financial-related stored procedures specifically related to Serbia Card, as part of a project for the USA.

We acted as a subcontractor for S&P within your company. I have extensive experience in SQL Server, particularly within the Microsoft environment.

They should think twice before they do anything and double-check. Definitely.

I have explored different options such as SonicWall and open-source solutions, but my preference lies with SQL Server. I find SQL Server to be fantastic, as it provides comprehensive functionality and makes tasks incredibly easy. 

Working with Postgres is also simpler compared to other databases like Oracle. Perhaps my familiarity with Excel has made SQL Server more intuitive for me. While I understand that Oracle is known for its complexity, I appreciate that its code and syntax bear similarities. 

Overall, I have a strong affinity for Microsoft products.

I would rate SQL Server a ten out of ten.