Friday, December 2, 2011

Meme Monday For December

It's Meme Monday time again. This month, Thomas LaRock (blog|Twitter) wants to know:

What gift do you want Microsoft to leave for you under the tree this year?

Hmm, let's see...Microsoft wouldn't give me an iPhone, would they? I'll guess I'll have to settle for a Windows Phone; I should probably start learning the Metro UI anyway.

Oh, and Santa Bill (or is it Santa Steve these days)? A few vouchers for certification tests would make nice stocking-stuffers, too.

Saturday, June 18, 2011

People Are Your Most Important Asset? - I Don't Think So

Our People Are Our Most Important Asset!

Donald Taylor posits here that people are an organization's most important asset.

Personally, I'd hesitate to work for a company that had that attitude.

On this blog, an organization's most important asset is data.

Although I wouldn't argue that a person is, "Something valuable that an entity benefits from, or has use of, in generating income", the complete definition of asset from businessdictionary.com is:
  1. Something valuable that an entity owns, benefits from, or has use of, in generating income.
  2. Accounting: Something that an entity has acquired or purchased, and that has money value (its cost, book value, market value, or residual value).
That doesn't sound right. Maybe we should dig a little deeper. Maybe people are tangible assets:
...anything that has long-term physical existence or is acquired for use in the operations of the business and not for sale to customers. 
A tad Orwellian, perhaps, but not too bad. Continuing:
...can be destroyed by fire, hurricane, or other disasters or accidents.
Gruesome, but true.
...can be used as collateral to raise loans, and can be more readily sold to raise cash in emergencies.
Stop right there.

How about intangible assets? Let's check that definition:
...the long-term resources of an entity, but have no physical existence.
Nope.

Sorry, I'm just not buying the idea that people are assets. So what are they?

I think a person is a resource:
An economic or productive factor required to accomplish an activity, or as means to undertake an enterprise and achieve desired outcome.
Now that's a person!

Let's wrap this discussion up with a couple of metaphors:
  1. Data is the fuel for the engine (the resource) that produces information.
  2. Data are the ingredients for the chef (the resource) to produce a meal (information).
Do you have any better examples? Do you agree or (more importantly) disagree?

PS: Some people don't like the term "Human Resources", but I always thought it meant resources for humans, not resources that are human.

Monday, June 13, 2011

Just A Big Ol' Spreadsheet

I've been thinking about my last post, and it occurred to me that some users probably think a database is nothing more than a big, interactive spreadsheet. Result sets are returned as rows and columns, and maybe their reports have graphs, just like in Excel. Heck, maybe they're actually using Excel as a front-end, so of course the database looks like a spreadsheet.

I know when I'm asked, "So what is a database, anyway?" I use a spreadsheet to explain it.

Maybe I have to come up with a better metaphor.

Monday, June 6, 2011

Meme Monday: Dumb SQL Questions

Once again, it's Meme Monday. Thomas LaRock's (Blog | Twitter) meme this month is dumb SQL questions.

First, let me express an opinion. I agree with the ideas that there are no dumb questions, or the only dumb question is one that isn't asked. But I think there are lazy questions, questions that could be answered with a little digging (or a quick Google search), but it's just easier to ask the DBA. I don't like lazy questions, and I try not to ask them.

Now, on to this month's meme. I don't really have a dumb question, more of a dumb attitude. It seems that a lot of end-users and developers think that creating a database takes about as much time and effort as creating a spreadsheet. They need it tomorrow, and don't understand when we start asking about schemas, tables, constraints, etc.

I suppose the DBA team needs to do a better job at education, but sometimes it seems like a lost cause.

Monday, May 2, 2011

It's Meme Monday Again

It's the 1st Monday of the month, so Thomas LaRock (Blog | Twitter) has another Meme Monday. Here's my list of Nine Things That Can Go Wrong With SQL Server That Don't Involve Disks:

  1. Users delete data they shouldn't.
  2. A memory module goes bad.
  3. Backup tapes get lost or damaged.
  4. The SA password is compromised.
  5. The network goes out, so no one can access the database.
  6. The requirements for a project change drastically at the last minute.
  7. The documentation you're using to try to fix a problem turns out to be wrong.
  8. Your mentor suddenly quits.
  9. Your raise is denied.

Saturday, April 30, 2011

Managing SQL Server Service Accounts

One thing I haven't been sure about is the best way to set up service accounts in SQL Server 2008. I know you should use a unique account for each service (Database Engine, SQL Agent, AS, IS and RS), but I was wondering about multiple instances. Is it a best practice to use a separate set of accounts for each instance, or (for example) should one RS account be used for all the Reporting Services on the machine?

After consulting Books Online (which says, "Run separate SQL Server services under separate Windows accounts.") and reading this editorial and the resulting discussion on SQLServerCentral.com, I decided that each service of each instance should use a unique account. Here's my naming convention:


You can see that I've collected the accounts into a Group named 'SQL Server Accounts', and that they follow this naming convention:
  • SQL - so all the SQL Server accounts will be listed together
  • Instance Name - 'PJM' in this case
  • Account Name - SQL Agent, Database Engine, Analysis Services, Integration Services or Reporting Services

Monday, April 25, 2011

When Is a Number Not a Number?

I've seen sample tables that have fields like Zip code or Social Security Number. These columns are invariably defined using an integer data type. I don't think this data is numeric; I think it's character data that happens to consist of all digits.

In my opinion, if an entity doesn't have arithmetic operations performed on it, then it shouldn't be defined as a number. 

Here's an example using SQL Server 2008 that demonstrates one of the pitfalls of using a numeric data type: leading zeros won't be displayed.  

CREATE TABLE ZipTest
(
 Zip1 SMALLINT,
 Zip2 VARCHAR(5) CHECK (Zip2 BETWEEN '00000' AND '99999')
)

INSERT INTO ZipTest VALUES(05678,'05678');

SELECT * FROM ZipTest

(1 row(s) affected)
Zip1   Zip2
------ -----
5678   05678

(1 row(s) affected)

These two values are obviously not the same.

So, to sum up (no pun intended): just because data looks numeric, doesn't necessarily mean it is numeric.

Friday, April 8, 2011

Meme Monday (So It's Late, So What?)

I just found out about Thomas LaRock's (Blog|Twitter) Meme Monday. Here's my (late) contribution:

The data is more important than whatever database it's stored in.
 
I'm not going to tag anyone, though.

Tuesday, April 5, 2011

Question of the Day

SQLServerCentral.com published my Question of the Day submission today! It's been pretty-well received so far.

I feel like I'm contributing something.

4/8/2011 Update:

It's probably OK to post the question now, so here it is.

Note: multiple commenters pointed out that option C should be phrased as 'The last INSERT statement will fail.'

Foreign Keys

What will the result of this code be?

USE AdventureWorks2008 
GO 

CREATE TABLE dbo.Students (
 StudentID INT UNIQUE, 
 LastName VARCHAR(20), 
 FirstName VARCHAR(20) 
)

INSERT INTO dbo.Students 
 VALUES(1,'Washington','George'),
       (2,'Adams','John'),
       (3,'Jefferson','Thomas')

CREATE TABLE dbo.ClassList (
 ClassID VARCHAR(6),
 StudentID INT REFERENCES dbo.Students(StudentID)


INSERT INTO dbo.ClassList VALUES('HIS101',4)

A. The ClassList table will not be created.
B. The code will complete successfully.
C. The INSERT statement will fail.

Correct Answer: 

C. The INSERT statement will fail.

Explanation:

You may think that a referenced key must be a primary key, but according to Books Online, a foreign key is linked to a primary key or unique key. Therefore, the ClassList table has a valid foreign key constraint, which prevents the record from being inserted.

Reference: Creating and Modifying FOREIGN KEY Constraints - http://msdn.microsoft.com/en-us/library/ms177463.aspx

Sunday, March 27, 2011

Welcome!

Welcome to Serving Data. Here, we'll be talking about data: what it is, what's it's good for, how to use it, manage it, store it and secure it.

To do all that, we'll need a Database Management System (DBMS). Since I've been tasked with learning Microsoft SQL Server at work, we'll primarily use that for the DBMS.

So, what's with the name? Why not "SQL Server Rocks", or "Living Among the Databases"? Because it's not the database that's important - it's the data. If the database is the kitchen, and the DBA is the chef, then the data are (yes, data is plural) the meats, vegetables, spices, etc. Which is more important: fancy knives and a high-end stove, or the best ingredients? Continuing the analogy, the finished meal that comes out of the kitchen is information. Information is different from data: data is raw facts, information is data plus meaning.

We can complete the food analogy to explain the 'Serving' part (can you tell I like to eat?). The main goal is to serve finished meals to the customers, but the food must be attended to, as well: it has to be stored and handled properly, the kitchen must be kept in good working order, and everything has to kept secure. So DBAs serve end users by making data available, but also serve the data by maintaining it.

So that's how the Serving Data blog came to be. We'll discuss almost anything related to data, and I'll share my experiences as I learn SQL Server 2008. Feel free to share or comment.

Thanks for reading.