SQL Server Reviews

Our correlation and relational databases are on Microsoft SQL Server.

The company uses two platforms: MySQL and Microsoft SQL Server. Some applications are on MySQL, and some applications are SQL Server. 

I have pretty much worked all my life in Microsoft SQL Server.

I am in the process of creating a data strategy to consolidate multiple siloed data centers. Once my plan is finalized and approved, then we are going to execute it on the Microsoft platform.

• Performance-wise, it is an excellent tool.
• It is a Microsoft product, so there's a lot of support. 
• It's not a new tool; it has been around for a while. 
• It is one of the top five relational databases in the market. 
• It is very user-friendly.
• There are a lot of resources available for it.

I would like to see native plugins built for other platforms versus having to buy third-party plugins to tap into S3 buckets and AWS Cloud. Right now, it does not have those built-in plugins.

I know that they are building SQL Server for the Unix environment, which is in the beta version, and not out yet. This has been a long time wish for a lot of people. Once that is out, we'll be able to tell how diversified they have become in regards to other platforms.

It hasn't 100 percent on scalability and third-party plugins.

It is one of the most stable relational databases out there.

With the new versions and Azure, which is in the cloud, these do accommodate scalability. Until the 2014 version, the scalability wasn't there, but from the 2016 version and above, I think they have taken all these scalability features into consideration.

I have not used technical support for Microsoft with my current company. I have used them in the past. It depends on the tier of support that was purchased by the company as to the level of support that you receive.

Our company has probably been using this solution since it was released.

It is expensive, but you get what you pay for.

Since we are a cloud-based company, there is AWS pricing on top of the SQL Server pricing. The Enterprise Edition can typically sell from around $1000 dollars a month, which is not cheap. Then, there is an additional one-time Windows cost, based on the code, which can go anywhere from $30,000 to $40,000 for the license.

From my perspective, the two vendors for this are Microsoft and Amazon (AWS).

They are working on making it better with every release, compared to Oracle Db2 and IBM.

I would definitely recommend SQL Server. It's not cheaper any more, like it used to be, but if you can afford it, then it's the best.

When I select a vendor, from a tool perspective, I make sure that they have full support available, have been in the market for awhile, and the solution/application is stable.

From an open source perspective, like MySQL, Aurora, and MongoDB, they have done a great job in making a robust database container.

Very pleasing and satisfying experience.

• Used to create queries
• Implemented store procedures
• DBA can also use this effectively.

• Used to create queries
• Implemented store procedures
• DBA can also use this effectively. 
• Reduces other manual work.

• Creating and executing SQL queries, transactions, ACID properties
• Creating and implementing stored procedures.

Every good tool has its own limitations. 

• First of all its cost. It is very high. 
• We need a good amount of RAM to properly use this. 
• Sometimes, query sticks in between. 

But our organization provides great RAM, so we don't have any issue with its speed.

No.

It's good.

No.

Go for it. Thumbs up.

The customer's MES system  use it.  The database system desgin as always on architecture.

Like Data guard in Oracle , always on contain double data and sync data by using transactions store in transaction log

It is easy to establish, and the license price is lower than that of Oracle.  

Otherwise, our customer could can replace primary databases from Oracle into MSSQL AG

Base on  windows cluster,  the always on no needs complicated config process.

Just click and click following  GUI interface.

table partition options,  that is very useful to separate unnecessary cost. 

For legacy data,  we can do partition swith out and store into flat files or old tables.

When it necessary, we can switch in back.

Horizontal partitioning.  

In that case,  cold , warm and hot data can be distributed into different database not only table partition located on different FGs .

Sometimes , when windows server suddently failed, the database still can be turn on when DB server started.

When do "sp_rename" or "table rebuild" , the cluster index or non-cluster index no needs to rebuild at same time

Customer always comes out many questions

I have no choice. our customer choose MS SQL 

 initial setup straightforward

ordinary level

database administrator

Migration local database into cloud

No, I  have to accepted it 

subpartition is necessary

• Effectiveness in a production environment
• New features test

Besides that, SQL Server has become very expensive like Oracle. Its stability delivers performance and usability.

• SSMS
• SSIS
• Reporting services
• FCI clustering
• AlwaysOn
• Basic availability groups.

I would like a mature real-monitoring built in into SSMS, even a trace file analyzer.

It is widely used and we never have problems with it. It can handle a PC, and it can also handle huge data. It is fast and efficient. It is something unique that tracks reporting of records, personnel, finances and more. It also integrates well with everything, not just Microsoft tools. 

It would be nice to search for specific value across multiple tables. This would save a lot of time. 

I have never had a problem with the stability of the solution. 

We have never really had a problem with the scalability of the solution. 

I have never used technical support. It is the joke at the office that you cannot get help on the Microsoft website at all. Also, downloading anything from Microsoft is usually a nightmare. Honestly, I end up googling the problem and solving it myself. This is definitely something Microsoft needs to improve.

It is definitely important for someone looking at a new vendor to consider the support of the solution. In addition, the customer should really do their research and understand what their needs are, and make sure the new solution will solve those needs. 

This is a departmental database engine which supports primarily localized solutions, data capture, and retrieval. However, with the exception of our aviation group, it is used for localized data lake or reporting solutions support.

It is cost effective with easy integration into the core MS Office tools. Hence user adoption is easy. Also, being a commodity product there is an abundance of cheap resources having experience with the toolkit, but very few senior or truly expert support personnel are available. Again because it is viewed as a commodity product even by developers, no serious time is spent on skills development with this toolkit.

Traditional DB toolkit closely integrated into Microsoft Office. This makes it truly easy to deploy in a light non-business critical environment.

• It does not scale up to a truly global environment. We operate in 220+ countries and territories with data services centralized in three data centers. The ability for MS SQL to operate in this environment is a challenge for anything spanning regions or having a global footprint. 
• It is best suited to supporting a single functional instance by business domain or a single country. 
• MS needs to work better at the WAN implementations transoceanic. 
• It also needs to have a less closed or less MS centric tool dependency as integration with other databases and non-MS development environments is always problematic.

The database is primarily used as back-end storage.

As an engineer working for multiple organisations, MS SQL has proven stability and operational power.

The additional tools, like SSIS and reporting services, make this solution useful.

Improvements to the indexing, columnstore indexing, and high availability groups are good improvements for future versions.

MS SQL is constantly improving their products. New options, such as managing with PowerShell, are good improvements.

I use SQL Server to optimize SQL queries and find the estimated cost of my queries. 

I also use it to fine tune my procedures and functions.

• SQL Server has maintained my database problem in an arranged manner.
• SQL Server Profiler makes finding and debugging easy.
• Support for third-party tools, like SQL Search.

• SQL Server Profiler: Know exactly which procedures and functions are being called and how much read and write they are taking.
• Tuning Advisor: It suggests where to add indexes and from where to remove them. It works like an adviser.
• Storage capability
• Debugger: The debugger tool can execute code step-by-step.

• Third-party services from Redgate should be built-in to it, like SQL Search.
• Debugging from the debugger tool functionality should be enhanced.
  

No stability issues.

No scalability issues.

It is good.

I have been using SQL Server from the start.

It was straightforward.

In-house.

It is good.

The setup cost is high, but it will return every penny.

All our main DBs run on SQL.

Ability to convert to bigger DBs. It makes it easier to move or upgrade between branches.

From a DB administrator perspective, I would like to see more space requirements and space capacity history, so that we are able to see which DBs are growing, and by how much per day or week.

No issues with stability.

No issues with scalability.

Have not used tech support.

Straightforward.

Plan ahead, and make sure do not pay for something you are not going to fully use.

Naming conventions are very very important. Make sure that your principle and mirror servers have the same disk space from the outset.

In the current organisation there was no centralised data repository. Thus, statistics, reporting, and generic management information were not existent. With the introduction of SQL Server, we have consolidated relevant business data into one main repository. We built reporting structures and analytics on top of the repository to help analysts and teams manage themselves, as well as provide management information. From basic or incomplete reports and statistics, we moved to a full reporting data structure, providing a holistic view of the organisation's data.

Without any doubt the Integration Services and Analysis Services are the most widely used. These are the basis for data quality, data gathering, ETL process, as well as collation for the data warehouse, Cube-generation, and ad-hoc processes. The ease in which you may mold a process flow or even modularly add in new structures is something which is much needed in my job.

An area that definitely needs improvement is the Reporting Service side with the actual report server. Although to be fair, Microsoft has developed a new branch of tools for reporting; presumably that is why they have not improved the Reporting Service side. Nevertheless, if this was not the case then, yes, it would be an area for improvement. Another area would be the SQL Server process monitoring, which is quite basic and could sustain more information.

Overall, SQL Server 2014 is a very stable product and so far I cannot remember major issues that I have encountered. The only item which I can list is application failure during Integration Services debugging, when restarting a process flow. In a number of instances the solutions fails. I have not given this much thought and simply stop and start the debugging service rather than restarting.

So far, we have had no scalability issues. I have read about instances where people encounter issues online, but fortunately enough I have never encountered issues.

Yes, in the past I have worked with different versions of SQL server and have switched due to upgrades to utilise the latest version. I have also used Oracle, Tableau, SAP, and Jaspersoft.

The main reason I went for SQL Server is because it felt easier and more adaptive. Also, most of the products we use within the organisation are Microsoft-based, so that provided an extra advantage over the rest.

Not too complex. We had spent a number of months on the design and planning stages, deciding how we would go about the setup, security, and accessibility aspects, so that when it came time for the actual setup, the process looked pretty straightforward. Don't get me wrong, it still took a number of days to finalise, but we had a concrete plan of action, the steps needed, and the work was delegated accordingly.

My advice is quite straightforward. If you know the number of users who really and truly need access to the Server then it is a no-brainer. If you do not know, then get the basic package and minimum licenses and start from there. Needless to say, users can develop/use data structures outside and then deploy onto the Server.

Within the current organisation, we did not look at other options. I was pretty confident that the product would do the job, based on my previous experience with similar products. One key factor which pushed us to choose SQL Server was the cost of the product versus the amount of work to develop/maintain.

I rate it eight out of 10. It is quite a good product and has improved dramatically. Like all products, it has bugs here and there and some areas still need improvement.

I have been using the solution for the past two and half years, however, I have worked with older versions of SQL Server (2012, 2008, 2005). The solution is quite powerful and versatile and I have not yet used all the areas/modules of the solution. It is not always easy to utilise all the available modules for the solution, especially if your work is focused solely on a particular area. Nonetheless, I try to use different areas for side projects.

Plan thoroughly before, and once implemented go through the structure regularly and remodel accordingly. When planning, go through all the various sections, resources, accessibility, security etc.