Re: Why all the max length constraints?

dawn wrote:
> 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.

Hm... it's not what I said, but I can live whith it.

> 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.

"is chosen" by whom? Who made the choice?

>>>>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?

Your "there should be no data entry widget that permits entry of more than 2 characters for a state code" tells me you have not digested that understanding.

> 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.

We can't have that, can we - should I introduce NOT NULL? Nah :-)

> I'm still left to guess precisely why what
> are sometimes called RDBMS's are implemented this way, while others
> might not be.

Which ones? I am really not nitpicking that DB2, SQLserver, Oracle and PostgreSQL aren't true R DBMS's.

> 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.

It would help if you acknowledged that the designers of the database have this reponsability, and not the designers of the dbms.
They (the designers of the dbms) have the responsability to provide facilities for the db designers to specify them, and the facilities to enforce the specified constraints. Received on Sun May 28 2006 - 16:47:20 CEST