Re: Why all the max length constraints?

mAsterdam wrote:
> 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?

Yes. I didn't start writing them until '77, but maintained some very old assembler-like code.

> Many of them were assembly programs crunched into COBOL syntax.
> Builders rely on what they know works.
>
> A related notion: form survives function.

Yes, that was my reason for mentioning cards in one post. I needed those fixed lengths when working with cards or anything that imitated cards on disk. I don't now, although I do need specifications of length for various representations. I would often prefer to store the entire value, whatever its length might be now that I don't have card columns to contend with.

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

I LOVE that tidbit -- thanks!

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

Very good.

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

Yes, although there could be considerable disagreement on what is conceptual. If a single external interface can only accept 'n' characters for a person's last name, wouldn't we still want to capture the entire last name anyway? In the worst case we might also accept an abbreviated version of the last name. Otherwise such workarounds as putting in all last names, with some truncated for some purposes and adjusting those that should not be truncated, would work. (My cousin really does not like it that someone she deals with, it might be a bank or credit card company, sends her important documents with a last name of Westendorp-Ho instead of Westendorp-Holland -- I'm guessing that someone named mAsterdam might appreciate that one. It would be a very bad idea for the insitution not to have her actual name, however.

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

Yes, that that might be the whole of it, unless there is also some efficiency issue that is necessary for this model and not others. It sounds like that is not the case, but I don't yet understand what is.

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

Right, but the feature of "wanting" such constraints is included by the dbms designers. It is just the serif issue? I so, I'll suggest it is time to make that which would ber analogous to sans-serif more common. Thanks. --dawn Received on Sun May 28 2006 - 16:05:41 CEST