Really long rows

I'm a curious fellow. Sometimes much to my chagrin. But every so often I come across something which kicks the old brain cells into gear and gets me to writing. Something that I think the world (or in this case the people reading this note) need to hear.

I was looking over some stored procedures the other day and discovered a stored procedure that returned a table with a large number of columns. A disturbing large number of columns. I lost count at around 240 or 250. What was particularly disturbing was that a relational set of tables was being compressed into a single row.

By way of example, image if you will a database that stored your personal information and all of the credit cards you had. For each credit card it recorded the date of the last payment and the amount of the payment. Now image compressing that relational information into a single row. You would have a column for VisaPayment and VisaPaymentDate as well as AMEXPayment and AMEXPaymentDate. While in a static world this may not be a problem, what if you get another credit card. The layout of that row would need to change because you now need to add additional columns. Indeed, every time you added a different credit card or, hopefully, paid off a credit card you would need to change the layout. This is something that is headed for disaster.

Refactoring. There, I said it. The code needs to be refactored. It may be working right now, but there is a brick wall coming up fast and the brakes are failing, so it either needs to be fixed or we need to take out a lot of insurance. Fast.

(Please note that this was a fictional example, sort of. Look at the code you're writing and make sure that it doesn't have this brick wall built into it.)