Author: way0utwest

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.