Re: Why all the max length constraints?
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.
Cheers. Received on Wed May 31 2006 - 00:42:58 CEST