Re: Pizza Example

Dawn M. Wolthuis wrote:
> I see no logic in this. The database need not constrain the size of data
> that is stored and the UI can either constrain it or not, as the
> designer/user see fit. Constraining the database to only store up to a
> particular length means that the database needs to be changed if a new valid
> value for an attribute arises that is longer than what was anticipated. The
> UI can permit scrolling to show only a limited number of characters, but
> scroll to show all. A report writer can wrap long values to a certain width
> for practicality. Unless there is a REAL business reason for limiting the
> number of characters for a value (or your DBMS product requires it or gives
> you better features if you do), don't do it. From what I have seen of RDBMS
> tools, those who use them are inclined to put an attribute of "color" in the
> database (for example) with a max number of characters for the value. All
> we need, then, is a new color to come available and you can bet that the
> name will be abbreviated now to keep it within that length. How silly IMO.

The logic is that is helps to enforce data integrity.

As a real-world example, I sometimes have to import data from a flat file into a database. Sometimes the people who create the flat file mess things up and give the columns in the wrong order or something.

If this happens when I have maximum sizes defined for the column widths, it usually will be the case that something will overflow and give an error. This is what I *want* to happen in this situation. If I just had everything at varchar(8000) it would all import with no errors except my database would end up hopelessly corrupted.

The downside is, as you say, that you have to be careful not to make the minimum column widths too small. But with a judicious choice of sizes this problem should be much less than the data integrity benefits.

Paul. Received on Mon Apr 05 2004 - 00:22:08 CEST