Re: Why all the max length constraints?

From: Alvin Ryder <alvin321_at_telstra.com>
Date: 30 May 2006 15:42:58 -0700
Message-ID: <1149028978.559748.185760_at_g10g2000cwb.googlegroups.com>


dawn wrote:
> Alvin Ryder wrote:
> > dawn wrote:
> > >
> > > 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?)
> > >
> >
> > Hi dawn,
> >
> > There is nothing in the RM that prompts these constraints, it mandates
> > only the existence of the boolean type, all other types are user (dbms)
> > definable.
>
> Helpful, thanks.
>
> > The constraints are related to performance, disk space management,
> > developer time, the languages used and computing in general.
>
> Again, helpful. Sorry I took a while to get down to this response.
>
> > > 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.
> > >
> >
> > Are you sure all the data is variable? Or is it limited to something
> > large like 2^32 (4Gb) which *appears* to be unlimited but in fact
> > isn't?
>
> Yes, you are correct that within the system there is a limit. In the
> logical/implementation data model the data are of variable length (but
> could conceivably hit some limit, requiring a change to the logical
> model)
>
> > Can attributes exceed the resident RAM size? Can they exceed the
> > disk size? I seriously doubt it.
>
> They cannot, you are correct. The developer does nothing with that at
> the logical level except to ensure that a single attribute would be
> defined such that its value would not logically exceed such a limit.
>
> > At any rate most RDBMs have CLOB types which provide something similar.
> > CLOB's aren't used as frequently as VARCHARs because they are much less
> > efficient. Again that has nothing to do with the RM but with computing
> > in general.
> >
> > > 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.
> >
> > Outputs and fonts are not database concerns at all so that isn't the
> > reason.
>
> Good.
>
> > Imagine a 32 bit integer versus an arbitrary precision number which has
> > any number of bits! The former only requires 32 bits but the latter
> > needs a way to represent the size and then you must represent the
> > variable length data itself. Which is easier? Which is faster?
>
> This would depend on your implementation strategy, I would think, but I
> understand the point.
>
> > The fixed length data might waste some bits but up to it's limit
> > everything is cut, dry and efficient. The variable length data is more
> > complex, slower and it isn't infinite after all.
>
> My understanding is that the MV databases have, in the past, been much
> faster than their counterparts that define individual attributes to the
> DBMS. This might not still be the case, but I would think there could
> be models for variable-lengths (data where individual attributes have
> no max length constraints specified) that are very efficient.
>
> > The same holds true or strings. And in turn the same holds for records
> > made up of such attributes. Furthermore once you store records on disk
> > what happens when they outgrow their current location?
>
> My concerns were about the individual attributes having a
> specification. I realize that there must be some "chunks" that are
> sized and tuned.
>
> > > 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?
> > >
> >
> > Yes you can write any system with variable length data but *no* you
> > cannot do it without cost. All of this has nothing to do with the RM,
> > we could be talking about word processors, databases or games. You just
> > can't have your cake and eat it too.
>
> I might have to ask something like this on cdp to get a perspective
> from someone who knows MV implementations, but my guess is that with
> their architecture as it is, that platform would suffer more if there
> were max length constraints. So, again, I'm thinking there is
> something about the RM, though not unique to it (even if just a
> statement that attributes must be defined to it, clearly not unique to
> the RM) that encourages a strategy of implementation that would be
> well-served with limits specified on the attributes, where other models
> might have no such advantages. Did that make sense? --dawn

No I can't follow how you went from guesses about MV implementation details to "there must be something in the RM". This leap lost me. I would think the best way to understand the RM is by way of its own literature and not by indirect inferences.

Tradeoffs between the fixed and variable occur everywhere in computing, it comes down to the laws of physics and available hardware. And to make any inferences you need "all things being equal" or "apples to apples" measurements, all else is just speculation is it not.

Cheers. Received on Wed May 31 2006 - 00:42:58 CEST

Original text of this message