Voice of the DBA

Author: way0utwest

  • Real Time Dangers

    There can be tremendous volatility in short term data.

    There seems to be a quest to move closer and closer to real time decision making. Gather data, analyze it, and make decisions instantly, preferably with the help oif expert systems. That makes some sense, and as shown in the article, it can allow analysts to respond to events very quickly, performing verification, fraud checks, or just about anything you can think of.

    It’s a good goal, and it can definitely help many companies make more informed decisions at any point in time. However there are problems as well. Sometimes short term data can fundamentally distort the picture of reality. Some of our large stock market meltdowns are the result of automated systems, perhaps not so much expert systems, as very quick reacting systems that might overvalue the last few pieces of data and make decisions that are less than optimal.

    We cannot program systems to handle every situation, nor can we even give enough guidance to inexperienced humans that might be involved in the workflow. Instead we ought to recognize that short term data might not represent longer trends and ensure that we have people looking over the data across a longer timeline before any important decisions are made.

    Too often it seems we build systems, assuming that more data, delivered quicker, is the way to prevent poor business decisions. We might easily overwhelm other systems, or people with too much data, delivered too quickly, or used to inform decisions too quickly. Real time systems can provide many benefits, but their use should be tempered with this saying I have long believed: computers give us the power to make mistakes quicker than ever before.

    Steve Jones

    The Voice of the DBA Podcasts

  • Quite a salary

    If this article is true, and I suspect it is for some software engineers, why aren’t more people learning programming?

    I think that we have a few problems in the industry, and I have an editorial coming out soon on this. One is that this type of money is rare. So many people work for companies and they make a good living, but they work hard. We have a perception issue of this industry being geeky, long hours, not a lot of respect, etc. I hear so many complaints from people that it’s hard sometimes to decide if they really like their jobs or they’re stuck in them, much like I hear complaints from people in accounting, or sales, etc.

    The other issue is that we haven’t done a great job of getting younger people interested in computers. We require more computer work in schools, and my kids use computers as much as I did when I was 12 and a geek, but they’re using computers as tools to produce an end product, not as a way to build another tool.

    We need to advocate, interest, and excite more kids about technology as a career if we want it to grow.

  • A view has no data

    I have seen quite a few posts and questions lately from people that are trying to change the data in a view, or move data in a view.

    A view has no data.

    It’s that simple. If you have something like this in AdventureWorks:

    SELECT firstname
, lastname
 FROM HumanResources.vEmployee

    And this view is defined as:

    CREATE VIEW [HumanResources].[vEmployee] 
AS 
SELECT 
e.[EmployeeID]
,c.[Title]
,c.[FirstName]
,c.[MiddleName]
,c.[LastName]
,c.[Suffix]
,e.[Title] AS [JobTitle] 
,c.[Phone]
,c.[EmailAddress]
,c.[EmailPromotion]
,a.[AddressLine1]
,a.[AddressLine2]
,a.[City]
,sp.[Name] AS [StateProvinceName] 
,a.[PostalCode]
,cr.[Name] AS [CountryRegionName] 
,c.[AdditionalContactInfo]
FROM [HumanResources].[Employee] e
INNER JOIN [Person].[Contact] c 
ON c.[ContactID] = e.[ContactID]
INNER JOIN [HumanResources].[EmployeeAddress] ea 
ON e.[EmployeeID] = ea.[EmployeeID] 
INNER JOIN [Person].[Address] a 
ON ea.[AddressID] = a.[AddressID]
INNER JOIN [Person].[StateProvince] sp 
ON sp.[StateProvinceID] = a.[StateProvinceID]
INNER JOIN [Person].[CountryRegion] cr 
ON cr.[CountryRegionCode] = sp.[CountryRegionCode];

    The SELECT statement is the same as running

     SELECT 
 c.[FirstName]
,c.[LastName]
FROM [HumanResources].[Employee] e
INNER JOIN [Person].[Contact] c 
ON c.[ContactID] = e.[ContactID]
INNER JOIN [HumanResources].[EmployeeAddress] ea 
ON e.[EmployeeID] = ea.[EmployeeID] 
INNER JOIN [Person].[Address] a 
ON ea.[AddressID] = a.[AddressID]
INNER JOIN [Person].[StateProvince] sp 
ON sp.[StateProvinceID] = a.[StateProvinceID]
INNER JOIN [Person].[CountryRegion] cr 
ON cr.[CountryRegionCode] = sp.[CountryRegionCode];

    Note this is exactly the same thing as the view definition with fewer columns included. Or it could be written like this:

    SELECT firstname
, lastname
 FROM 
 (
SELECT 
e.[EmployeeID]
,c.[Title]
,c.[FirstName]
,c.[MiddleName]
,c.[LastName]
,c.[Suffix]
,e.[Title] AS [JobTitle] 
,c.[Phone]
,c.[EmailAddress]
,c.[EmailPromotion]
,a.[AddressLine1]
,a.[AddressLine2]
,a.[City]
,sp.[Name] AS [StateProvinceName] 
,a.[PostalCode]
,cr.[Name] AS [CountryRegionName] 
,c.[AdditionalContactInfo]
FROM [HumanResources].[Employee] e
INNER JOIN [Person].[Contact] c 
ON c.[ContactID] = e.[ContactID]
INNER JOIN [HumanResources].[EmployeeAddress] ea 
ON e.[EmployeeID] = ea.[EmployeeID] 
INNER JOIN [Person].[Address] a 
ON ea.[AddressID] = a.[AddressID]
INNER JOIN [Person].[StateProvince] sp 
ON sp.[StateProvinceID] = a.[StateProvinceID]
INNER JOIN [Person].[CountryRegion] cr 
ON cr.[CountryRegionCode] = sp.[CountryRegionCode]
 ) a

    In this case I’ve moved the view definition into the FROM clause of my SELECT query.

    A view is literally a stored query that you can use to make it easier to write code. There is no data in the view, so if you need to change the data, or “refresh” the data from another database, you need to move the data in the tables that are referenced in the VIEW.

  • Going Green in Software Development

    We use a little solar power at the ranch, making us a touch more "green"

    I am very interested in a better use of the electricity we use on this planet. I think energy production from non-fossil fuel sources will be important in the future, and I’m regularly examining the energy usage at my ranch, calculating the cost of wind, solar, and other energy production technologies to see if any of them are a good investment. I believe that our future will both require and consume more electrical energy. That’s fine, but I think that we ought to be looking to be more efficient in how we use energy, which will require an effort to build and use more efficient devices.

    Many authors write articles and speak about techniques that you can use to build more efficient applications. The most popular sessions given by speakers and requested by attendees are those that deal with improving performance. Writing better code, troubleshooting issues, and increasing the efficiency of our systems are under our control seem to be the priorities for most IT workers that I know. Every time we build something a little better, it’s a great win for the author.

    Intel published an interesting article that talks about the impact that writing better code might have on energy usage in applications. Computers use different amounts of energy under different loads. More intensive computations use more power than the idle thread that occupies the CPU during low usage periods. I don’t know how much power I’m using at my house for computing, but I plan on measuring it, especially after reading this post from someone that calculated his power consumption.

    Power is becoming a more of an issue for many data centers. The cost is rising and becoming a significant percentage of the total expense of operation. While data professionals tend to work on server systems, which share the load from many clients and might not have much idle time, there still could be room for improvement. Writing better, more efficient code that requires less reads, less CPU cycles, can end up reducing the cost of operation. Maybe that’s a reason to ask for a little larger training budget and learn how to write better, non-RBAR code (as Jeff Moden would say).

    Whether better code could save a significant amount of electricity is hard to know, but in most cases, it doesn’t take any more time or effort to write more efficient code than poor code: if you know how. You probably have plenty of reasons to learn to write better code, but here’s one more. Writing better code might help you feel a little more green.

    Steve Jones

    The Voice of the DBA Podcasts