Re: Why all the max length constraints?

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Sun, 28 May 2006 00:14:41 GMT
Message-ID: <RX5eg.41165$mh.17709_at_tornado.ohiordc.rr.com>


dawn wrote:
> [OK, here is my next "stupid question" as I cut a path in my study of
> the RM. Those teachers who just want to tell this student how ignorant
> she is are welcome to sit this out as I really am hoping to
> understand.]

[Quiz time: what are scalars, tuples, and relations?]

> In SQL-DBMS's, like VSAM (and other indexed sequential files before
> them) a lot of attributes are specified with max length constraints.

I don't mean to pick nits, but I don't grok "VSAM" and SQL-DBMS's.

IIRC, VSAM provided for an OCCURS-like construction in record layouts - but all that meant was that you could have a variable number of fields, all of fixed width, up to some specified maximum. MicroData, Pick, Progress, &c, mean very different things when they describe things as variable.

> While there are some attributes where this constraint is related to a
> conceptual constraint (from the analysis phase), these lengths are
> often introduced for the logical model or implemenation in the DBMS.
>
> In other words, when mapping from the conceptual (analysis) to the
> logical (design) data models (pick the terms you like best for these),
> these constraints are designed for many attributes that have no such
> conceptual/business limits (if implemented with a paper system, there
> would be no such limit, for example).
>
> Is there something about the RM that would prompt all (or most?)
> existing implementations (however flawed) to drive developers to add in
> these constraints for performance, space saving, or other reasons?

No.

> I
> realize there can be variable length attributes, but specifying a max
> field length still seems to be the norm (is that still the case?)

Yes.

> As many of you know, I work with database management systems that treat
> all data as variable in length, while one might specify a length for
> display purposes.

I can't imagine that it's useful for 'Smith, Joseph' and 'Smith, John' to appear as identical values when, say, displayed in a field of eight characters. I also work with products where all data are of variable length. (There is a maximum, but it's huge.) PITA. This mis-feature accounts for a fair number of support calls.

> Thanks for any insights into database attribute length constraints,
> their purpose (is it related to output with fixed fonts, database
> performance, size or what?), and any correlation to implementations
> (again, however flawed) of the RM,

The issue has nothing to do with the relational model.

if there is such. Could a vendor
> write an implementation of the RM where length constraints are as rare
> as they are in the conceptual model without introducing performance or
> any other issues?
>
> TIA. --dawn
>
Received on Sun May 28 2006 - 02:14:41 CEST

Original text of this message