Voice of the DBA

Category: Editorial

  • Learning C

    Head First C
    I think C is important to teach the basics of programming.

    Someone else gets it. Besides me, I mean. We should be teaching people the C programming language. An interview with David Griffiths, author of Head First C, says that learning C is a good idea. I concur, and I stand by my statement.

    It’s not that I think everyone should be a C expert, but I’d like to see more programmers spend 5 months, a semester, early in their programming careers. If you’ve written your own iOS app, this would be a piece of cake. If you’re a Python guru, it would broaden your horizons. Getting closer to hardware helps you write code in a more thoughtful way.

    I’d like to see a C programming course as a semester requirement for quite a few fields that might need to develop programs. Not only computer science majors, but also scientists that might need to deal with building their own algorithms. In the same vein, perhaps it’s worth a SQL class for everyone to better understand how to work with sets of data. A query class could also include some of the other query languages, perhaps MDX and XQuery would make sense as well.

    I know this sounds like busy work, but as we become more and more dependent on data and scripting for all sorts of jobs I think it makes sense to start setting a baseline of expected skill for knowledge workers. Those people that knew programming could potentially pass a C test,  and they would be exempt. As we evolve into the future, especially as we may move to more vocational type training, I think it would be good to still require some basics of people as they begin their journey to working with code and computers.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Milk

    cow
    It’s amazing how much knowledge goes into selecting cows for milk production.

    I love this quote: “[we] ran it through a fairly sophisticated computing gobbledygook. It spit out at the other end predicted transmitting ability, predicted genetic values of whatever sort.”  How would you like to explain your complex analysis to a business user using those terms? In most cases, those might be the best way to describe things to most users.

    However that quote comes from a scientist that has spent a lot of time and knowledge refining models and using lots of data to try and predict the bulls whose progeny will result in the best dairy cow performance. The article is very interesting and talks a bit about the complexity of using genome data on cattle and how far it is from the experiments Mendel performed on pea plants. I still remember the dominant/recessive gene explanations from biology, though that explanation seems simplistic now. Comparing it to the work done by scientists predicting cow performance is like comparing horse drawn carriages to Formula 1 race cars.

    Big data is in the news, with so many companies building products they want to sell to help you tame, analyze, and use the data your organization has available. However as this article hints, it’s much more than managing all that data. There is a tremendous amount of knowledge and intelligence needed to use those tools and actually generate useful information.

    As data professionals, we don’t necessarily need all that knowledge, but we do need to communicate with those individuals that may have the knowledge and work closely with them to ensure their ideas are accurately applied against data in the algorithms we write. In addition to writing code and understanding statistics, strong communication skills are important to moving your career forward.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • No Limits

    Google Compute Engine
    No limits for the Google Compute Engine, at least not any practical limits.

    We’ve had Amazon Web Services (AWS) available for some time, and used for some interesting projects that wouldn’t be possible if groups had to purchase their own equipment. From password cracking to cancer research, there are some amazing possibilities. Windows Azure works as well, and there are customers such as banks, using the cloud to perform complex analysis of data. Not to be left out, Google announced recently they were provide their Google Compute Engine to anyone, without any limits on scale. You have to pay for it, but if you want 770,000 cores to solve a problem, they’ll provide them if you can pay for the resources. It’s US$2m/day, but it’s there.

    I don’t know what that means for us as data professionals, but I suspect there will be any number of companies that will consider using these types of resources to work on complex analysis of problems. Running a simulation might be something that costs a few hundred dollars a day, using resources for minutes at a time. Looking over some of the different projects people have used cloud computing engines for, it seems that many businesses might find this to be a cost effective way to perform data mining or BI type workloads.

    If you can get the data to the engine. I still wonder how challenging this is, apart from all the security concerns. Just moving that much data around, refreshing it, removing the stale data, could be very complex. It concerns me that as more people attempt this type of work, we will have more and more poor decisions made because of data quality, age, or accuracy. After all, garbage in, garbage out has been a tenet of data professionals for decades.

    If you’re using cloud resources for computation, I’d love to know about it. I know many of the data professionals out there have reservations, and that’s healthy. It shouldn’t blind you to the possibilities that this is a most cost effective way of actually getting analysis and answers for your users.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Separate Accounts

    Separated Strawberry
    Is separation that much of a hassle? I don’t think so.

    Many years ago I worked in a small company that only had about 5 or 6 servers. We had one system administrator whose job it was to manage all the servers. One day our sysadmin was on vacation when there was a problem with the Exchange server. One of the other developers worked on the system and ended up fixing it, but changed the service account password while doing so. The next day I walked into the office to find a group of people stymied as to what was wrong with the development server and version control system. Everyone claimed they hadn’t changed anything on that server, and they were right. However our admin used the same domain account for all servers, including my SQL Servers. I changed the SQL service account that day.

    One of the recommendations that I learned a long time ago, and one that I make regularly, is that every SQL Server instance should have a separate security account. In that case, I had separate accounts created for each database instance, and for each SQL Agent instance. We used long, random passwords that were never stored, and if we needed to access a password, we just changed it. That kind of flexibility and separation prevented any crosstalk issues between services, and it allowed us to easily alter permissions or passwords for one service without affecting any others.

    The other day I saw someone recommending a single service account for all SQL Servers. Someone else recommended a single account for each version of SQL Server, using separate accounts where it’s really needed. That’s a better recommendation, but I still prefer completely separate accounts. I know that some security groups don’t like that, but is it that big a problem? This Friday I wanted to ask you about your experiences.

    Do you find separate accounts for each instance (or Agent) to be a security or administrative issue?

    I’m not sure why this is unwieldy. Service accounts rarely change, and you could easily script changes to a group of accounts with PowerShell or some other tool. Once I set a service account, the only thing I might ever do later is alter the permissions to add access to a folder. When that happens, I definitely want to have separate accounts for each instance.

    Let us know this Friday how you feel and what works for you.

    Steve Jones

    The Voice of the DBA Podcasts

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