Voice of the DBA

Category: Editorial

  • The Knowledge Graph

    Google aims to use a "database of everything" to satisfy search queries.
    Google aims to use a “database of everything” to satisfy search queries.

    Google does some amazing things. In many ways I like the company and their emphasis on data. I’m not sure I’d want to work there or fit into the culture, but the company tackles some problems that could really change many of our daily lives. They experiment with many projects, one of which is the driverless car project. I’m particularly interested in seeing seeing how that might influence the world.

    One of their other projects seems more ambitious. The Knowledge Graph project aims to use a database of everything in the world (according to this piece) and provide even more information to people using the Google search engine. In addition to search results, the idea is that you can get other facts and information about the topic you are searching for.

    Whether it works well or not, it’s certainly an interesting idea. Can we build engines that can divine the context of what we are looking for? If we can do this often enough, then the idea of interactive computers, like the ones on Star Trek, might be closer than we think. Perhaps there’s a way for us to actually mine the data we have about a customer, or a situation, and present results that are more relevant and useful. Perhaps we can build software that can do more than just automate tasks and can help us better analyze information with new ideas or concepts as it interacts with us.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Acing an Audit

    Good procedures built into your processes should make passing an audit very easy.
    Good procedures built into your processes should make passing an audit very easy.

    I’ve been through relatively few audits in my database career. I’ve worked in a few industries that didn’t require them, and avoided the stringent requirements of PCI and HIPAA. ISO 9000 was the first audit I encountered and I had been preparing for Sarbanes-Oxley (recently passed) when I left that company to come work for SQLServerCentral.

    The preparation for an audit required a lot of work, meetings, and organization. The first time I suffered through an ISO audit, I was amazed at how much of our daily work was interrupted and the time spent ensuring we would pass the audit. The second time wasn’t much better, though I’d instituted some processes and controls for the DBA group that did reduce the amount of preparation needed for our portion of the audit.

    I wish that more companies I’d worked for had actually built the controls, security, and documentation into their processes. Maybe then they’d only need a 30 minute window to prepare for the audit. That’s what an insurance company needed to do recently according to this piece. I found many of the rules and regulations required in the ISO and SOX documents to be ones I’d want to implement for my database systems. The hard part was getting management to agree and implement the rules as part of our daily work.

    I did find it interesting that the company had built their own software to match their processes and allow employees to work efficiently. Lots of companies have struggled with the idea of becoming their own software company, but if software is truly going to be an important part of most businesses, perhaps it’s a good investment for most of them.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Still 32

    I was listening to a presentation recently and the presenter talked about some of the restrictions in working with 32 bit SQL Server on 64 bit Windows hosts. Another person joked that any companies still running 32 bit software were way behind the times. I heard a comment that surely everyone runs 64 bit hardware these days, don’t they?

    Do they? How many servers in large companies are still running on the x86 architecture? I know I have old laptops still running those processors, though I’d like to think that most companies have a hardware refresh rate that’s no longer than 5 years, and most laptops and servers would be x86.

    The platform architecture, however, doesn’t necessarily imply our software has been upgraded to 64 bit. There are problems with various drivers that won’t run under 64-bit architectures. Excel is often a problem as SQL Server moves to 64-bit versions. There are 64-bit drivers, but the change, testing, etc. effort for many companies may not be worth pursuing. It can be annoying for us data professionals, but it’s a valid business decision. The same argument often applies to those companies running SQL Server 2000 (or older versions).

    Five or six years ago I heard a presenter that worked for a large Fortune 100 company say that their policy was for applications to last ten years. That included the hardware and software, since the cost of change, whether through new software or major upgrades, was significant. With many companies still running SQL Server 2000, I suspect that many companies have a similar, unofficial, policy.

    I don’t know whether the majority of software we use in our careers is 32 bit or 64 bit, but I am sure that we will have to deal with the former for years to come. You can complain about it, but you better learn to work with it.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Serverless Software

    Developers may never see groups of servers like this again in the future.
    Developers may never see groups of servers like this again in the future.

    I love the words “loosely coupled.” At times in my career, I’ve built software and have aimed to ensure that processes, workflows, and components worked well on their own. In the places where I had to work with data or services on different physical machines, I tried to ensure that each item would run separately, and communicate when needed, but wouldn’t fail if another machine was down.

    That’s kind of the idea proposed in the article that says the future of software is serverless? It’s an interesting read, talking about the advances in cloud services that can change the way developers build applications. Developers should think about liking services, and pieces of applications, ignoring the idea their systems are tied to specific servers.

    It’s a future that I think makes sense for most environments. Development shouldn’t be concerned about the size or care of physical machines. Instead they should think about building on a platform of services, and expecting the scale to grow or shrink as needed, without code changes.

    I do think this could be the future in which development proceeds inside companies, as well as for commercial software. However vendors need to sell “private clouds” which function in the same way as the public ones, for those companies that want to control, and invest in, their own hardware.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.