Voice of the DBA

Category: Editorial

  • Challenge Yourself

    I am a proponent of blogging as a way to build your brand. Your work showcases your knowledge, thought process, and interests. It provides a way for potential employers to perform due diligence and determine if you are a good fit for their team and position. Blogging can also help you to learn more about your craft and focus your learning. After all, it’s been said that if you can’t explain something to others, perhaps you don’t really understand it.

    As I meet people, and talk to them about blogging, I often get asked “what should I write about?”. The easy answer is to write about the things that you do on a regular basis, the problems you solve at work, and the solutions you implement. However, what do you write about if you don’t do much at work and are looking to learn new topics. If you want to show that you are building experience with SQL Server in a way that isn’t required at your current position?

    I think it’s easy, and I’ll give you a few ideas. First, build a lab at home. These days it’s easy (and free) with VirtualBox and a little memory, both of which can be had for relatively small investments. Next, start following the #tsql2sday tag on Twitter and challenge yourself to get a post written every month. However don’t stop there. I keep a list of previous topics and you can go back and write a post for every one of those topics. Your effort won’t be in the recap, but you’ll force yourself to learn, or at least explain, your thoughts in those areas.

    If you want additional challenges, read a question like this one on splitting strings. Don’t read the replies, but try to answer the question on your own by writing a blog that explains your solution. You can link to the post and show how you would solve the issue if you encountered it. If you want to press yourself further, go through my list of article requests and pick one. It doesn’t matter if the article has been written and published or not. Write your own solution on your own blog, as I saw Jason Carter do here for this request on exporting XML files. Feel free to submit your post as an article, and maybe we’ll publish your solution as well.

    There are so many ways to challenge yourself and learn more about SQL Server that it could be a full time endeavor by itself. Please don’t make it one, and remember to balance your career growth with the rest of your life. However, do continue to work regularly on your career, and showcase your knowledge. It’s good practice for your communication skills, and you never know when you might count on the wide breadth of knowledge you’ve documented to help you land that dream job.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Database Checkups

    I am most definitely a fan of continuous delivery (CD) and the idea that we have the ability to both release our software at any time, for any change, but also have the process and mindset in place to rapidly push enhancements and patches through our development process. However I’m also no naive enough to think that the processes of Agile, Lean, Scrum, Continuous Integration, or any other methodology make this happen. It requires belief and effort by your entire team, including management, to evolve your software quicker.

    There is a downside. The faster, and more often, you release changes to your production system, the more likely you are to cause an issue. This isn’t really any different from traditional waterfall processes, which also cause issues in production, but it does mean that the perception of issues is a bit changed. People expect higher quality when they implement a CD process, and while quality might be higher (there is debate on this), it certainly isn’t perfect.

    Walgreens has implemented a CD process, and they rapidly deploy changes, but they’ve also had issues. In fact, there’s a piece that talks about an issue during a database deployment, and offers some guidance on preparation to deal with problems in your deployment process. The ideas of monitoring (which is critical), planning for recovery, coordinating development, etc are all things that we need to do in any production environment, but they are especially important in a CD process where people expect changes quickly. Whether those changes are enhancing the application, or rolling back a problematic deployment, they need to happen quickly.

    Over time, which may be decades, I expect that more and more organizations and end users will expect patches and changes to their software to happen in the background, while the system is being used. This might mean we need to plan for application architectures with sections that can be upgraded separately, or maybe we will develop ways to modify executable code without ending the process. In either case, the ideas behind CD will become more and more useful, and the more you understand them, the better off you’ll be.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Is SQL Server Mature?

    When I asked recently what compelling reasons there are, or aren’t, for upgrading SQL Server, it seems cost was the issue for most people. I can understand that, especially as licensing for VMs has made it an expensive endeavor to upgrade their systems. Many, many companies have started to revisit their policies regarding upgrades and seriously evaluate the decision to undertake a version change. While I’m not sure if many companies are starting to look at keeping all instances of SQL Server for ten years, I know many are looking to keep their noncritical systems on the existing versions as long as possible.

    As I read through the posts on my piece, I found this great quote from one of the commenter: “I’m a great believer in “If it ain’t broke, don’t fix it” and so if a system is running acceptably for it’s purpose, I’ll leave it alone.” To a large extent, that’s how I’ve viewed systems. If things are working, it becomes hard to justify an upgrade. In fact, I had a client that was running a SQL Server v6.5 instance in 2005, a full ten years after that version was released. Why? Mostly because the database backed a card key system that worked. While the database wasn’t supported, neither was the card key system, and since an upgrade would have been close to $100,000, it wasn’t worth performing. We did upgrade to a virtual server to remove hardware dependencies, but otherwise left the system alone.

    That brings me to this week’s question, which is one that I’ve asked myself for years: Is SQL Server mature?

    If a version of SQL Server can handle the load placed on it, is there any good reason to upgrade. I suspect that for many applications, the base features of SQL Server are good enough. If these features have performed well for a number of versions, then why change? While I like the changes in T-SQL, especially error handling, I’m not sure those changes are worth paying tens of thousands of dollars for. I’m not sure the improvements are really justified for many applications, and I’m not sure many developers can even find the time to implement them.

    More and more I think that key to continued adoption and growth of SQL Server is licensing by scale, not edition, and not by feature. Just like Azure, let me pay for the cores and RAM I need, and let me easily grow that as needed.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn. 

     

  • The Value of Data

    How valuable is your data? It’s a good question, and certainly the type of data your organization has along with the business in which you are engaged will make your data more or less valuable. More and more we find the differentiation between companies is in the way they collect, manage, and use the data available to them. So much in business is based on guesses, but more and more the guesses have some basis in data. We are starting to see those who make decisions in business feel some need to justify or support their choices with data.

    Is data the new oil? Oil was arguably the most important commodity of the twentieth century (and perhaps still is). The SQLRockstar wrote a piece with that same title, with the idea that knowing more about how valuable data can be will make you more successful in business. The post is based on the review of Predictive Analytics: The Power to Predict Who Will Click, Buy, Lie, and talks about some of the challenges of using data to make decisions.

    I certainly believe in the power of data, and that more data often gives us more insight into how the world works, as well as allowing us to draw some inferences about the future. Not necessarily better insight, but certainly more. I do think that computer extrapolation of patterns to the future is vastly overrated as most of our algorithms are far too simple, using too little data and discounting the increasing effects of small variables as scale increases. In short, I don’t think we’re anywhere close to a Foundation-like computer that can help us predict the success of new products, much less the future of a country.

    However I think that using analytics to make small decisions, and help guide our directions is important. We will still need humans that apply their internal supercomputers to interpret data, and continue to evolve the algorithms, and I hope that more and more of you are gaining deeper industry insight in your particular field. After all, many of us data professionals will be needed to help guide analysts in gathering, transforming, interpreting, and displaying data in ways that allows us to make decisions with more confidence.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn.