Re: Why all the max length constraints?
Date: 28 May 2006 09:49:19 -0700
Message-ID: <1148834959.696716.196330_at_38g2000cwa.googlegroups.com>
mAsterdam wrote:
> 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 can't. Somehow I ended up cut and pasting someting that truncated "stated length" to "state" in two instances. Oops. (Maybe I was only permitted 5 characters? ;-)
> > 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?
The application software designers in line with their users (not those who wrote the dbms toolset, if that is the question)
> >>>>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.
No, it tells you that I have not adopted it as my own opinion. I understand, and do not write-off, your point. It still isn't mine, however.
> > 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 :-)
>> > are sometimes called RDBMS's are implemented this way, while others
> > I'm still left to guess precisely why what
> > might not be.
>
> Which ones?
I seems like all the big ones are such that those using them seem to always select max lengths, so I asked if it was the case and if so, why those who wrote the DBMS did not make that optional without penalty (or did some of them?)
> I am really not nitpicking that DB2, SQLserver, Oracle and
> PostgreSQL aren't true R DBMS's.
>> > might just be tradition, but in any case, I'd like to understand
> > 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
> > better.
>
> It would help if you acknowledged that the designers
> of the database have this reponsability, and not the
> designers of the dbms.
Yes, the database designers select max lengths, and the dbms designers choose whether and how big a penalty would be if size were not declared.
> 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.
And the option to provide a feature permitting app or db designers not to specify a size., the option to default to variable length unless otherwise specified, for example.
Thanks! --dawn Received on Sun May 28 2006 - 18:49:19 CEST