Re: Why all the max length constraints?

J M Davitt 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.]
>
> [Quiz time: what are scalars, tuples, and relations?]

You define scalar and I'll define tuples and relations. btw, I think my def of relation is already in the cdt dictionary.

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

It is not a nit pick for you to point out things you don't fully understand.

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

Indexed sequential files were a natural progression from cards. It is easy to see how fixed lengths arose out of working with card decks. I wondering if the concept was simply never dropped or had a reason for continuing.

> MicroData, Pick,
> Progress, &c, mean very different things when they describe things as
> variable.

The first two should mean the same if you are referring to MicroData Reality. There are some good stories on the splitting of ways between Dick Pick and Don Fuller, but yes, I'm sure that "variable" is used for different things.

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

Obviously not if truncated. The default with Pick would be to wrap in any display. This is usually good, but has its own issues too, of course. For every solution...

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

What is the best mitigation strategy in your case? If you know that an attribute must have no more than two characters, what do you do?

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

I know nothing of how dbms products are designed internally. I have this idea that possibly the fact that everything in XML, Pick, and elsewhere is ordered gives them more of a likelihood of permitting variable length and handling it well since you can tag-delimit values.

Is there possibly something about how RDBMS's would need to allocate space for columns or something that might make it advantageous for there to be a max length? The other thought I had was that working with sets and joins might mean that implementing with everything variable length could be problematic for allocation of space somehow, but I (obviously) don't know.

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

Is your answer to this question "yes"? If so, why hasn't anyone done so? It seems it would help with the goal of decoupling the physical from the logical. If there is no conceptual reason for a limit, couldn't the dbms take care of such physical issues?

I'm looking right now at all of the aspects of a conceptual design that need to be adjusted in what I was calling the logical (data) design (the one implemented by means of a person or program interfacing with the DBMS) and how such designs are done differently using the RM (or an implementation thereof, however flawed) or MV.

Thanks for your help. --dawn Received on Sun May 28 2006 - 03:32:00 CEST