Re: Why all the max length constraints?

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 28 May 2006 10:40:39 +0200
Message-ID: <4479614c$0$31648$e4fe514c_at_news.xs4all.nl>


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

To really answer any question relating to this we'ld have to operationalize this observation by establishing what to compare with ("a lot") and by counting max length/non-max length attributes at a significant number of sites using different solutions for data-sharing, and ... Oops we don't have the resources to do so.

My hunch is that you are right.
("a lot" interpreted as more than in the delivered conceptual models).

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

Did you ever see COBOL programs from the early days? Many of them were assembly programs crunched into COBOL syntax. Builders rely on what they know works.

A related notion: form survives function. Look at those little bars in 'serif' fonts: when you cut out characters in stone or wood, you first make a little bar in order to prevent splicing their media when they carve the big bar. They needed the little bars (serifs).
Many files on mainframes initially had a recordlength of 80 - why? Cars started like coaches without horses.

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

In a way of speaking they dropped the serif for storage purposes, but not for display purposes.

> Thanks for any insights into database attribute length constraints,
> their purpose (is it related to output with fixed fonts, database
> performance, size or what?),

When there is a real, practical reason for adopting some attribute max length - think of external (outgoing) interfaces - the max length should be in the conceptual model.

> and any correlation to implementations
> (again, however flawed) of the RM, if there is such.

The explanation along the above lines would be carry-over: The early adapters had a lot of max-length limitations in theire existing solutions.

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

The length contraints are specified by the designers of the database, not by the designers of the dbms. Received on Sun May 28 2006 - 10:40:39 CEST

Original text of this message