Re: Why all the max length constraints?

dawn wrote:
> J M Davitt wrote:
> > But, you know, there is always a "max length." It may
> > be a large value, but it's there.
>
> Yes, understood. My question is about the logical data
> model (pick your favorite name for it) -- the definition
> of the schema to the computer. Why give a max length to
> an attribute that doesn't conceptually require such? Why
> can't the DBMS handle that for you (efficiently, of
> course)?

Who says they cannot? Do you realize that even if no DBMS implementation has yet done so, this is not evidence of impossibility. This is a classic example of argument from ignorance or the burden of proof logical fallacy. And yet you imply this fallacious claim from the start of the thread. Do you understand this is a logical fallacy?

Furthermore, as others have pointed out already and in other contexts, implying that deficiencies in DBMS products imply problems with the relational model is even more fallacious.

> > There are already many products that can do that. But
> > adding the phrase "without introducing performance or
> > other issues" is naive. You should know better;
> > everything has a cost.
>
> I'm referring to run-time issues. Of course there would be
> a cost to change a product.

Umm ... I'm fairly sure that JMD was /also/ referring to the usual time (and space) costs. Not some type of "product" inertia. Especially since he said believing otherwise would be "naive" as of course time/space/abstraction cost analysis is fundamental in computer science.

> At run-time, fewer constraints could be a performance
> boost.

This is totally misleading. /Runtime enforcement/ of constraints /may/ reduce performance. However constraints by themselves are performance neutral as clearly it depends on how those constraints are implemented. Perhaps they are implemented at compile time. Perhaps they are free on particular hardware (integers modulo 2^32 on a 32-bit machine for example). Etc. Etc.

Furthermore, /knowledge/ of constraints allows increased optimization and hence a performance boost. It seems obvious that one force behind this historical attraction to fixed size domains is the easily obtained performance benefits. Let us again note this has nothing to do with the relational model. You know of course that ISAM (part of your original topic) predates the RM? And isn't ISAM basically synonymous (historically) with fixed length records?

> I can't think of any reason why MV systems would be faster
> if there were max length constraints in the DBMS, for
> example.

Ok, I'm sorry but this ... this seems absurd. I cannot rectify your statement with this quote from your (this is you correct?) Dordt bio:

  "I have been an Information Technology professional for   more than a quarter of a century and now have my own   business. I am taking time off from that to teach   Computer Science and Mathematics at Dordt."

You are teaching computer science and you "can't think of any reason why MV systems would be faster if there were max length constraints in the DBMS"??? These are basic, core, fundamental issues here. Either you

1. are joking
2. are exaggerating
3. don't "feel" like taking a moment to think
4. are unqualified to teach computer science anywhere

Seriously which is it, Dawn? If you truly meant what you said then may I suggest you forget about data models, DBMS, relations, etc for a time and focus simply on scalars and domains. Specifically, please examine the history and current art of implementing strings. From examning string implementations alone you will learn a great deal about time/space/abstraction/constraint costs/tradeoffs etc. Then you will have no trouble "think[ing] of ... reason[s] why MV systems would ..."

> Your answer makes me think there is something about the
> way RM implementations (or approximations thereof) operate
> that is enhanced by knowing how many card columns are
> required, thereby prompting developers to specify this
> physical design and limit the implementation unnecessarily
> (in ways the conceptual model need not).

Your posts make me think this is what you /want/ to believe. That this is what you /feel/ not think. that you are looking not to learn but rather to have your prejudices reinforce themselves.

> > This is not what others are referring to when they
> > mention separation between logical and physical design.
>
> I know ;-)

Then please use terminology in a way consistent with the community here. Why do you refuse to do this?

> > > I'm looking right now at all of the aspects of a
> > > conceptual design that need to be adjusted ...
> >
> > That's a step down the wrong path. How could any
> > subsequent design effort change the conceptual model?
> > It's either complete and correct
> > -- or it isn't.
>
> No, no, I'm mapping the conceptual model for the purpose
> of implementation. The conceptual model, the business
> requirements, might not have a limit on the size of a
> color attribute, for example, but then in the
> "implementation model" or what I and others have called
> the "logical data model" we add in a length of 12
> characters, for example.

No, no, you said you were looking into "adjusting" the /conceptual/ design. Then you both contradicted and agreed with JMDs point that you do not "adjust" the /conceptual/ design you implement it! Or perhaps in your words "adjust" the "mapping" (or dawn-called "logical model").

Look, if you honestly want to learn about why many DBMS implementations gravitate toward size constraints, is it really so hard to find out? There must be papers, reports, books, etc that examine and discuss various implementation choices.

Perhaps you are right and there is something beyond the usual, typical, basic design tradeoffs (that any computer science teacher should know). Something special and unique to RM. Something buried deep in the bowls of corporate archives. Something hidden. Something profound. Something that Codd knew and tried to hide. Something that confirms the supremacy of Pick's genius. Go forth Dawn! Find it! Do the research and blind us all with a dawning of new light.

• Keith ---