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.
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.
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.
Initially as a post-transactional database, but now it's mainly a transactional database and for Analysis Services.
It's a very capable, efficient, price-performant OLAP server on which we can build our solutions.
Analysis Services, because we are an independent software vendor in the business-intelligence area.
The web interface and the command line interface could be better so we could manage and build some things around an API. If we could build our own solution, our own interface, and then manage the solution through that open API, that would be better.
With the new, big releases, there's quite a lot of work that we have to do. From 2005 to 2008, and then from 2012 to 2016. But, otherwise, it's quite stable. It's nice.
Even for us, it's quite okay. For the type of customers we have now, it's okay. But, for a big amount of data, when we are speaking about IoT Segments, and Big Data projects, there are performance issues.
If there wasn't Stack Overflow, that would be a problem. But luckily there are also other resources on the web which we can use to help ourselves. Just depending on Microsoft support it would not be so great.
We used PostgreSQL, and we also used some other OLAP servers.
It's more and more complex. The 2005 version was very nice and neat, but now it's more and more complicated.
The price has been going higher and higher. The market is quite price sensitive.
At that time there was also Sybase, Oracle, MySQL. That's at the time those databases were up.
It's good if you need OLAP services.
I give it a seven out of 10 overall, because of the things mentioned: First is that during the version upgrades, sometimes things are complicated. The second thing is the support is not so... without an open-source community it would not be so good. Third is the pricing, because it's changing, sometimes it's confusing.
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.
Usually I install an SQL Server as part of something bigger from Microsoft (NAV, CRM, SharePoint, SCCM, SCOM, BizTalk, etc.) or some custom built solution that was designed around this DMBS.
I also teach in a university. My students admit that SQL Server is quite easy to install and work with if you are a total beginner (compared with others).
I am not sure, as we have been working with it from the start. Comparing with other database management systems that I tried in other companies, SQL Server is quite easy to install, configure, and maintain. It is also quite reliable in cluster configurations and has helped me to reduce downtime and improve SLAs. If backups and alerts are configured properly, I can also rely on my restoration plan saving my butt more than once.
Always On is my favorite feature. I do like availability groups and cannot imagine how I lived with them before.
Microsoft tries to release new features with every version, but I cannot say that they are killer features. Usually these are just "nice to have" stuff. However, SQL Server works and it works just fine. It is really reliable if you don't shoot your own leg. All the basic functionality is 100% bulletproof.
I like it the way it is, though I would appreciate a dark theme for SQL Server Management Studio and ability to add databases with TDE enabled into availability groups.
I am aware of Connect and Trello pages, and there are a lot of good ideas from other people, most of them are useful only in some very rare scenarios. There are interesting suggestions present, and Microsoft should pay more attention.
Over the years, there was one service pack and two cumulative updates that were recalled as problematic ones, but otherwise it is very stable system.
Unfortunately, SQL Server cannot be scaled out so easily as some NoSQL solutions. There are some options that may allow it to work with quite enormous workloads. For example, try to google how Stack Overflow is built (yes, it works with SQL Server). They have quite an interesting architecture.
It depends. The shear number of support specialists is huge. You can get a freshman or a seasoned veteran. Usually, it is tolerable but it might take a while to solve a problem. In my experience, 50% of all problems can be resolved by installation of the latest patch. In 25% of times, it is your own stupidity. The 25% that left are real bugs, exotic configurations, and rocket science-level problems with a real high-load and very specific code and environments.
It depends how many features you want to implement. Basic stuff is very easy to install, but if you want to implement all the features or deploy a high-load or a clustered environment, it might be tricky. That is why you need a good architect and skilled DBA for something really complicated.
I have seen everything. It always depends on people skills. To get full performance from the SQL Server you need a well prepared environment and hard team work.
This is a downside of enterprise Microsoft products. Currently, almost all of my machines are in Azure and I think it is the best way of licensing now (VM+software).
Though I do like the SQL Server, I must say it is very hard to find a good DBA nowadays and having a DBMS without a DBA is like having a car without a driver and skills to drive it yourself. Before choosing or switching to this DMBS, check what kind of workforce is available in your area.
You may consider Azure SQL Database as a simple alternative, but I would advise it only for small workloads though.
It allows me to obtain access to data that I would not otherwise obtain access to from different programs. It has helped pull statistics and data, then put it into a report form to do some Power BI on it. This really helps people above me to view what we are doing, how we are doing it, and how to improve it.
Overall, it just makes your job simpler.
It is a simple query language. It is consistent across all versions. If you start with an older version, move to the newer version. The same code will still work.
It can go easily on a virtual machine and be accommodated by a virtual machine easily. That is a plus, as not all databases can handle that. It also will do clustering, so you can have two database servers looking at the same data simultaneously.
You can always access the data. You could have an offsite and an onsite, and if the onsite goes down, the offsite picks it up. I like that flexibility to provide continuing operations.
Right now, the tool you use to query the system updates every month. It pesters you to update the Client every month when there is nothing new that you really need to add, but it is constantly pestering you. I do not care for it.
I have no problems with stability at all, even when they are clustered.
Scalability depends on the version. I have to know ahead of time what version I need, but that is typical of all database software. However, as long as I build it correctly, it works great.
I have not had support for the SQL Server product.
This is Microsoft, so you just buy a ticket and they will just work with you until it is fixed. However, I have not had any issues where I needed to contact them.
We previously used MySQL, because it is a free product. It was just hard to operate, do backups, and make automated. Also, it was not scalable.
Initial setup is real simple. Just install it. Though, I recommend for new users to at least look online for training or a manual.
It has the easiest licensing.
We are a Microsoft shop, so we use Active Directory. That integrates well with this product, but we did look at Oracle. We also looked at IBM. This was the best price point for us for what we were getting.
We use it
Ease of use.
The free version is cumbersome to use and maintain. But $5000 for a licence is more expense than the benefit I would get from a licensed version.
No stability issues.
We are capturing 1 million calls per month. The free version can’t scale this much data.
Never used. Google is sufficient.
Postgre has a weird syntax and it is slower than MS SQL. The command line interpeter makes it complex to learn.
MS SQL is the easiest of the three I tried.
A licence might be worth the price to simplify management and speed up searches.