Comments on: How to choose SQL column types: a case study http://www.xaprb.com/blog/2006/02/07/how-to-choose-sql-column-types/ Stay curious! Sun, 20 Jul 2008 22:56:33 +0000 http://wordpress.org/?v=2.2.2 By: What is SQL? http://www.xaprb.com/blog/2006/02/07/how-to-choose-sql-column-types/#comment-8188 What is SQL? Tue, 22 May 2007 09:18:07 +0000 http://www.xaprb.com/blog/2006/02/07/how-to-choose-sql-column-types/#comment-8188 I'd appreciate some more examples, especially for MySQL and SQLite implementations. I've been googling "best practices" all day and there is very little information regarding the semantics of choosing column type, only the technical side of the story is well documented. I’d appreciate some more examples, especially for MySQL and SQLite implementations. I’ve been googling “best practices” all day and there is very little information regarding the semantics of choosing column type, only the technical side of the story is well documented.

]]> By: Nik Hughes http://www.xaprb.com/blog/2006/02/07/how-to-choose-sql-column-types/#comment-796 Nik Hughes Wed, 24 May 2006 17:34:00 +0000 http://www.xaprb.com/blog/2006/02/07/how-to-choose-sql-column-types/#comment-796 <p>You point up two problematic mindsets that "We Techies" need to try to overcome. While "Think Carefully" is a good moral, I think it goes beyond that. It isn't just thinking, it is being less selfish/ego-centric. Most of our work is ours for a very short time. After we are done creating it, it becomes the users' product. And the maintenance programmers' product.</p> <p>So in thinking, you suggest that we should ask the semantic question: "How easy will it be to understand this later?" I think it would be useful to ask other questions like:"How is the data entry clerk going to use this?" "The manager reading reports?" "How easy will it be for my successor to change/expand this in the future?" Think about all the others who will be impacted by our code.</p> <p>For example, I've had folks from the business side swear up and down that a particular document identifier would <strong>never</strong> be larger than 10 characters. The first inclination is to pick the smallest column size possible. Naturally, if I believed them, I would probably pick <code>VARCHAR(10)</code>. </p> <p>Naturally, they lied. </p> <p>(Not because they are Evil or Stupid. But because the world changes, more sources of these documents get set up, and there is more complexity to model. So my First Cautionary Rule remains "The client always lies.")</p> <p>No problem! A quick <code>ALTER TABLE</code> and the problem is solved, eh?</p> <p>Well, yes. Except that data in the database never stays there (and would be totally useless if it did.) So we have the 600+ reports that need to be validated to make there is enough space to display additional characters. We have the data exchange files that pass this information to other organizations. We have the 3000 dynamic web pages that need to checked. For each one, it might be fine; it might be a problem. But you have to check. </p> <p>So now, years later, some poor maintenance programmer gets to pay for my inability to predict just how big the lie actually was.</p> You point up two problematic mindsets that “We Techies” need to try to overcome. While “Think Carefully” is a good moral, I think it goes beyond that. It isn’t just thinking, it is being less selfish/ego-centric. Most of our work is ours for a very short time. After we are done creating it, it becomes the users’ product. And the maintenance programmers’ product.

So in thinking, you suggest that we should ask the semantic question: “How easy will it be to understand this later?” I think it would be useful to ask other questions like:”How is the data entry clerk going to use this?” “The manager reading reports?” “How easy will it be for my successor to change/expand this in the future?” Think about all the others who will be impacted by our code.

For example, I’ve had folks from the business side swear up and down that a particular document identifier would never be larger than 10 characters. The first inclination is to pick the smallest column size possible. Naturally, if I believed them, I would probably pick VARCHAR(10).

Naturally, they lied.

(Not because they are Evil or Stupid. But because the world changes, more sources of these documents get set up, and there is more complexity to model. So my First Cautionary Rule remains “The client always lies.”)

No problem! A quick ALTER TABLE and the problem is solved, eh?

Well, yes. Except that data in the database never stays there (and would be totally useless if it did.) So we have the 600+ reports that need to be validated to make there is enough space to display additional characters. We have the data exchange files that pass this information to other organizations. We have the 3000 dynamic web pages that need to checked. For each one, it might be fine; it might be a problem. But you have to check.

So now, years later, some poor maintenance programmer gets to pay for my inability to predict just how big the lie actually was.

]]>