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.

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.

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?

Nothin' is guaranteed, mAsterdam, I undertsand your point.

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.

It sounds unanimous so far.

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.

.