Voice of the DBA

Category: Editorial

  • Data Sprawl

    When I was starting in the computer industry, it seemed that we had many choices for platforms, but once we had decided on a direction, the companies I worked for standardized on those systems. It seemed that there was less interoperability between vendors, or even subsets of products from those vendors.

    That’s changed and these days I see products from different hardware vendors, different OSes, different development languages, even different database platforms being co-mingled and mixed throughout all sizes of companies. I see developers moving from Windows to OSX to Unix without a blink and data professionals going from SQL Server to MySQL to Hadoop easily.

    Well, maybe not easily. Certainly there are challenges in learning how MySQL operates differently from SQL Server, which is a long way from the import and processing of data in NoSQL systems. However I do see some SQL Server professionals rising to the challenge and learning to work with these disparate technologies.

    It seems to me that many of us in the future will need to develop multiple skill sets with different technologies just to be effective. Many of our companies will continue to deal with more data sprawl as not only will data be stored in RDBMSs and Excel, but we’ll get cloud services, NoSQL systems, and more that contain sets of data our organizations want to combine together.

    We have seen XML and Hadoop integration in the SQL Server platform, with both R and JSON coming in SQL Server 2016. While I don’t know that any of these will come to dominate data analysis, I do think that it will behoove data professionals to be sure they keep their ability to learn sharp by experimenting with new technologies and growing their skills. Your company might not use Hadoop (or any new tech), but if you don’t learn about it, you won’t know if it meets a need you have.

    However, even if you don’t decide to use the technology, the effort spent learning about it will not be wasted. Your brain will be more flexible, and you’ll have less anxiety if you’re asked to take a look at a new technology, maybe graph databases, something that is probably wildly different from anything you’ve ever used.

    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. feed

  • Who’s a Good Developer?

    I hear people in all industries and careers say that all of us should hire the best person for the job. We should pick the most qualified person and engage their services. However what’s left out of most of this advice is the most important question: how do you measure the best?

    We talked about this recently in a DLM Workshop led by Ike Ellis. He asked the question: how do you tell who’s a good developer? Think about it for a few minutes. I’m sure you (think you) know who the best developer or DBA is in your company, but how do you know? What’s the measure?

    I suspect you’ll find it to be a very abstract idea. Perhaps it’s like pornography, where you know a good developer when you see them, but if so, then have you always been able to tell a good developer right away? In an interview?

    Embedded in the idea of determining who’s good and who’s not is the idea of ranking. Is there any way to rank one developer over another? I think you might be able to do so, but only in broad ranges. We (as a group) might feel Developer A is better than Developer B, but not necessarily better or worse than Developer C. However, do we have any way of ranking these two that would stand up to outside analysis?

    I don’t have any great ways of measuring one developer v another. A best I think you can trust a developer to get a particular project done, and to the satisfaction of the client. However the trust would be based on previous experience and not any objective measures.

    This isn’t likely to be a problem that we will solve anytime soon, in any industry. I think the best way to gain confidence in someone is to examine their body of work. See how it matches up with the work expected from an individual and then cross your fingers, trusting they continue to perform as expected.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The History of the VCS

    I’ve been looking for ways to convince more DBAs to use a version control system for their code. I realize that many of you have gotten along without them for years, but that doesn’t mean it’s a good idea. A VCS is like a safety net, and someday you’ll be glad you have one.

    Recently I was reading about the history of VCS, and ran across some interesting posts. One on some amazing things, and another that has a timeline, showing us to be in a Renaissance period. If this is the Renaissance, then what comes next? I can’t even imagine, but I suspect someone will improve the process.

    It’s incredible to think about the ways in which we’ve managed versioning code in the past. I’m sure most of us have used comments to both document as well as preserve old code. Some of us have worked with simple backups of files, one per day (for a week or month), or dealt with a first generation system where only one person could work with a particular file.

    The move to CVCS systems, like TFS or Subversion, was a major improvement, allowing everyone to work on all the code, and merge their code with others when they needed to commit. That’s a system many of us inherently understand. It’s what we would do in an offline system. However the DVCS systems (Git, Mercurial), are much more complex, and they can be confusing. However separating the ability from committing changes to performing the merge can be valuable, especially in distributed development.

    More and more tools are integrating version control, including for database code. Whether you like or hate TFS, it includes lots of additional functionality to allow bugs, features, and other workflow items to link to the VCS items that solve them.

    The choice of which system works well in your environment will probably be driven by arguments from your development staff. Some will prefer one interface over another or feel the need to work offline, but I’m not sure it really matters which system you choose. I’d pick one of the modern CVCS or DVCS systems and use it.

    That’s what’s really important; you need to use the system and track your code. It’s frees you as a developer, allowing you to clean up your code, remove excess comments, and easily find out what worked (or didn’t) in previous code.

    Steve Jones

    The Voice of the DBA Podcast

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

  • ER Modeling

    I saw someone recently note that an Entity-Relationship model is important for your database development project. That UML is important, and the model should be actively maintained. I agree.

    However, I’ve usually not seen this done. Typically when I’ve seen an ER diagram in a shop, it resides on a wall, printed out on multiple sheets of paper. Often there are as many handwritten additions on the pages as there are marks from a printer. The diagram is also usually out of date, even allowing for handwritten notes.

    Maintaining a diagram is hard. Deciding to actually spend time working on one instead of just talking about a few entities and building them, may be harder. This week, I wanted to ask you if you’re up to the challenge in your organization.

    How many of you maintain an ER model for your database?

    Do you have an ER diagram you’ve built? Whether it’s in ErWin, Visio, or Paint. Is there a diagram that’s actively maintained and that everyone can use for designing changes to the database(s) in use? Do people actually consult this and use it in design meetings? Let us know this week.

    Steve Jones

    The Voice of the DBA Podcast

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