May 2, 2011 at 11:47 am
My limitations are budget related, not vendor specific. While I'd love to have some of the nifty third party utilities and can justify the need based on ROI, it's not going to happen here. Free or open source utilities are fine as long as they are safe.
May 3, 2011 at 2:40 am
Unless the DBA owns the company, it is not 'his' data, it is the company data.
All company employees have a duty to do their work in the most effective manner, and for the DBA this includes looking at what toolset provides the best cost/risk/benefit advantage to the company. Part of a manager's duty is to review the costs, risks, and benefits presented by the DBA and decide if the money should be spent.
Some companies may decide to keep 100% within the Microsoft stack, but this may restrict the company from exploiting all the business opportunities available to it.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 3, 2011 at 5:26 pm
I slightly disagree with several statements that Microsoft does work not good enough. It is not fair because the comparison is stupid.
Almost all 3-d party vendors produce niche software while MS does not.
SQL Server is a great DB server from almost every perspective. The difference is that Microsoft cannot produce software or tools for every single purpose we want. For instance, MS does not develop the best solutions which relate to backup compression, extensive monitoring, etc. However, MS produces substantial solutions like SQL or Exchange Server for everyone (users or small software companies).
Do not think that MS should do all possible features in the world. But, taking into account SQL Server, MS works up a market because the commodity is good enough. Not just a simple marketing.
I have been used SQL Server for last 10 years. That is why I prefer to adhere MS solutions or at least solutions by vendors which have high-quality MS support such as Quest Software, etc. I agree to use third party solutions but just if software vendors can resolve every single problem working directly with MS.
Overall, my opinion is grounded on reliability of solution which I want to use. As a result, I am open to use 3-d party solutions if they are reliable enough to utilize in production.
May 3, 2011 at 5:48 pm
I agree, we are a Microsoft Gold partner, but have never really used the support much. Did try a couple of times.
I try and use SQL Server tools to do a job when i can. But there are times when it is much more efficient 7 time saving to just use a third party tool.
May 4, 2011 at 2:03 am
I think it seperates into 2 areas
- 3rd party products your software may come to rely on (e.g. expansion of functionality, 3rd party dll's, etc.)
- 3rd party products that enhance/speed up your system indirectly (e.g. development, exploration, monitoring, profiling, etc.etc.)
With the first, your product may become dependant if using them. Where I am I tend to avoid this where possible as our environment here is not really set up to support going far off `out the box MS`.
The second, to me is more about working smartly, faster, more efficiently and effectivly - i.e. you could remove these products if anything were ever to happen and carry on (all be it with possibly far more manual overhead). Here I am far more likely to/to be able to use something 3rd party.
M. 🙂
May 6, 2011 at 9:45 am
As was mentioned above, this argument could be made for any business-critical component, not just databases. What about a product that interacts with Active Directory, for example? That being said, I believe that anyone with the mentality of maintaining a homogeneous environment for the ease of troubleshooting a potential problem at some future point should NOT be in the position of maintaining such systems. They are creating a drag on productivity. They obviously have no troubleshooting skills themselves, no ability to perform fault domain isolation, and have no faith in their personnel who work for them on troubleshooting issues.
Over the past 25 years I've been in I.T. I have worn many hats and have worked for corporations large and small, usually in a mission-critical/high visibility settings and I have been on the hook for troubleshooting many issues. A couple of things I have learned from my experiences are:
- Most often, my troubleshooting skills are better than those of the product vendor.
- Rarely was the problem the interaction between software products from different vendors.
--Brian
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply