Re: Why all the max length constraints?

From: dawn <dawnwolthuis_at_gmail.com>
Date: 28 May 2006 06:44:06 -0700
Message-ID: <1148823846.714963.165160_at_g10g2000cwb.googlegroups.com>


mAsterdam wrote:
> dawn wrote:
> > Marshall wrote:
> >>dawn wrote:
> >>>[why all the length constraints?]
>
> [snip]
> >>Realistically, if you have a field for state/province, and someone
> >>enters 6 megabytes of character data, something has gone wrong
> >>somewhere.
> >
> > Yes, and there should be no data entry widget that permits entry of
> > more than 2 characters for a state code, for example, more likely
> > selecting from a drop-down.
>
> If the state code fields (*) in the database are defined
> as having 2 characters, there is a efective max-length
> constraint of 2. Now it doesn't matter wether there is
> a data entry widget that permits entry of more than 2
> characters for a state code. The data in the the database
> is garantueed to not violate this specific constraint.
>
> Another constraint set/type (ISO country-codes) would
> be tighter, of course, and the user interface could
> well be more sophisticated by using them.
>
> (*) Not phrased in RM terms to show that this
> is a general database issue, not RM specific.

Yes. You are saying that if the data type is a state, then you want to define it as a state to the DBMS so that the typing can be enforced. I understand that. But even in cases where there is no conceptual max on a value (last name, for example), a max length is chosen for the attribute definition to the dbms.

> >>Better to trap it around character 255 than to
> >>let it just run along sucking up resources.
> >
> >
> > I do want the software product (as a whole) to limit
> > anything which has a conceptual limit.
>
> This is a reason to put the conceptual limits as
> close to the data as possible. If they are enforced in
> the database the rest of the software product
> has to follow suit. Any other way isn't
> garantueed, is it?

Nothin' is guaranteed, mAsterdam, I undertsand your point. I'll just say that if there is such a constraint, then the overall solution must enforce that one way or another, over time, optimizing integrity, maintainability, etc. I'll otherwise sidestep your question as it might relate to my latest blog entry on constraints, and I understand I've only addressed a tiny piece of the puzzle and there is much more that could be said regarding cases where there are business rules to be enforced.

For this question, I'm interested in cases where there is no such conceptual constraint.

> >>There is nothing specific to RM here.

It sounds unanimous so far. I'm still left to guess precisely why what are sometimes called RDBMS's are implemented this way, while others might not be. Possible answers have been: 1) it has to do with the representation of the data, helping developers not have to truncate or decide how to abbreviate if they don't have enough space in some input or output document. 2) it helps for optimization.

I was aware of the benefits and problems of 1). I was guessing 2) was the case, but would like to better understand why the implementations are such that these individual numbers help enough to require them (except with clogs, and it would be practical to implement an Oracle solution with all strings declared as clogs) while in other implementations they are not deemed important enough to require. It might just be tradition, but in any case, I'd like to understand better.

Thanks. --dawn Received on Sun May 28 2006 - 15:44:06 CEST

Original text of this message