Category: Uncategorized

I had a minor panic attack recently where I was getting ready for bed and all of a sudden thought that I’d forgotten to get the newsletter, or an editorial done. And I didn’t have anything to write about.

Sounds like a bad dream for a writer, and it is. Reminds me of the nightmares I used to have waiting tables where I’d be at work, but constantly falling behind, unable to get people their food or drinks, getting more and more tables, and having complaints coming back constantly. Usually those occurred when I was working lots of hours.

That’s not the case here. I feel busier, and more pressure at times, but the last week hasn’t been overloaded at work. This week has been tough, with family stuff interfering with work during the day, and I’ve been running behind, but not panic’d.

My supply of editorials, however, has been low. There have been two times this year where I went to go shoot a podcast for a couple days away and I realized that I didn’t have any editorials written. Lots of half-written ones, but I had to spend quite a few hours trying to polish something off. Some of them haven’t been as good as I’d like them, and that bothers me.

I used to really worry about running out of things to write about. In seven years I’ve learned that I shouldn’t be worried, and that something will come, but I can’t get overconfident either. I need to work at this on a regular basis.

Something that’s sometimes harder to do than at other times.

I used to think that I would run out of things to write about, but a decade after starting to blog regularly, there’s no shortage of ideas.

If you’re starting out on a blog, however, it can seem like you’ll solve all your problems quickly and be left with nothing to write about. That’s not the case, and I’ll give you a few ideas on how to find things to write about.

Work

I assume you are solving problems, fixing things, writing code, etc. at work on a regular basis. Anything that you solve, any new situation that you work on can be a blog post.

Maybe you just learned how to recover your database to a point in time, or for the first time you setup replication. Take a few minutes  and jot down some notes and then write about what you did. It doesn’t have to be a lot, but you ought to be able to get a few paragraphs out of it. Pretend it’s a status report for your boss.

Or even make it one.

Twitter

Twitter can be a great source of inspiration. Or Facebook, LinkedIn, a user group, or any place where you can interact with peers. Twitter is nice in that you don’t have to know someone to follow them and see what they post. If you find someone in your field, watch what they post, and write your thoughts about it.

If you know the solution to their question, write what you know, say you saw this on Twitter and it reminded you of a time when you solved this with x and y.

If you don’t know, spend a little time researching something and write about what you learned.

In either case, you are showing off a little knowledge and that can be very attractive to a potential employer. You never know when someone needs a person to do the x and y that you wrote about in your blog.

Forums

One of the best ways for me to learn was to answer questions in discussion forums. It’s also great blog fodder. You can answer someone and then write about how you solved the problem, or you could even write the solution as a blog and post that as the answer.

In either case, it’s showing off some of your knowledge.

Be Consistent

I’m sure if you take a look at these areas you’ll find more things to write about than you expected. However don’t get crazy and publish a dozen blogs a day. First it’s not sustainable, and second, it looks like you’re blogging more than working. It’s a lack of balance.

Write when you can, but schedule posts out when you have more than enough for the current day.

I wrote about data types recently, referencing Michelle Ufford’s presentation at the PASS 2009 Summit. In that post I talked about how using a smaller data type can make a difference in the way your indexes work and improve performance.
However there’s another thing you can do as well: vertically partition your tables.
A vertical partition is a way of dividing up your table. I’ll give you an example from my past. I used to work for an online training company, and we had all sorts of education products. We had a table similar to this one used for our customers.

create table Customers
( CustomerID int identity(1,1)
, Firstname varchar(50)
, Lastname varchar(50)
, Address1 varchar(50)
, Address2 varchar(50)
, city varchar(50)
, state varchar( 50)
, postalcode varchar(20)
, countryID int
, province varchar(50)
, status tinyint
, active tinyint
, balance numeric( 10, 4)
, CompanyID int
, notes text
) 

This was on SQL 2000, so TEXT was the data type we used.

In this table, we often joined our customers with other tables to display things on various pages. We wanted to grab their name almost all the time, but we also regularly queried with companyID, balance, status, and active. Those flags and FKs were used in different queries, so building a covering index could work, but we couldn’t cover all queries. We could have multiple indexes, and we did, but since there were always varying queries coming up, we did this instead.

create table Customers 
( CustomerID int identity(1,1)
, Firstname varchar(50)
, Lastname varchar(50)
, status tinyint
, active tinyint
, balance numeric( 10, 4)
, CompanyID int
) 

create table Customer_Details 
( CustomerID int identity(1,1)
, Address1 varchar(50)
, Address2 varchar(50)
, city varchar(50)
, state varchar( 50)
, postalcode varchar(20)
, countryID int
, province varchar(50)
, notes text 
) 

If you notice we’ve essentially split this table into two tables, keeping CustomerID in both, but otherwise separating out fields. In the main Customers table we keep those often queries values, the ones that are used in most queries. In the Customer_Details table we have moved those fields that are less often queried.

This does two things. One is that indexes, clustered and non-clustered, are smaller in the first table. Even a lookup to the data means that more rows are pulled in with every page read. That translates into more information for every read, and quite possibly less reads to get to your data. Less space in memory needed to cache things, and likely better performance.

And the larger the table, the more increases in performance you might see.

This isn’t necessarily the best design for all tables, but if you have busy tables, and there are disparities on how often you use some fields, but not others, this is a technique to consider.

Note that you can always build a view that combines these tables as a way to still see the same view as you have now.

I’m doing a basic presentation at the Rocky Mountain Tech Trifecta later this month on what SQL Server is from a basic viewpoint. I had a request for this at the SQL Saturday #17 in Baton Rouge last year and I’ve been meaning to get it written. Apparenltly there are a decent number of developers, managers, PMs, etc. that attend events, trying to better understand technology and it seems that we don’t often get to a basic enough level for them.

So what is SQL Server? A set of Excel spreadsheets? Is it a filing cabinet? Is it a library? Is it a storage mechanism or something more complex?

You’ll have to see the presentation to get my thoughts. However I would be interested in analogies or ideas that others have for explaining SQL Server to a manager, a new developer, or maybe even your Mom or kids.

I’ll try to record a version and stick it up on the Internet at some point.