Why all the max length constraints?
Date: 27 May 2006 16:52:02 -0700
Message-ID: <1148773922.267863.170930_at_j55g2000cwa.googlegroups.com>
[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. 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?)
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.
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, 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 - 01:52:02 CEST