Re: Why all the max length constraints?

Keith H Duggar wrote:
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.

Or, then again, we could just blame Hollerith for fixed length fields. Oh wait, maybe that's the same thing? Or should we blame Jacquard? Or maybe de Vaucanson? Or even Falcon?

One might as usefully rant against the evils of EBCDIC as the evils of fixed length fields.


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.

Dawn teaches at Dordt or is she a student? I suppose either way it is much less suprising that she cannot distinguish science from religion. After all, Dordt is a religious school that refers to Darwin's theories of natural and sexual selection as "evolutionism" and refers to "Christian and non-Christian approaches" to science as if religious faith has any bearing whatsoever on the scientific method.

If she pretended to teach anything to anybody there, I would suggest the students demand their tuition back; except, the sort of people who pay for a degree from that sort of institution probably got exactly what they wanted.
.

Relevant Pages

  • Re: Why all the max length constraints?
    ... Do you realize that even if no DBMS ... constraints /may/ reduce performance. ... (in ways the conceptual model need not). ... mention separation between logical and physical design. ...
    (comp.databases.theory)
  • Re: Why all the max length constraints?
    ... implementations of the RM have taken the industry a bit astray from ... them) a lot of attributes are specified with max length constraints. ... I know nothing of how dbms products are designed internally. ... developers to specify this physical design and limit the implementation ...
    (comp.databases.theory)
  • Re: Why all the max length constraints?
    ... Do you realize that even if no DBMS ... That would be the reason for my question. ... constraints /may/ reduce performance. ... dbms vendor who is attempting to base their design on the RM to end up ...
    (comp.databases.theory)
  • Re: Struggling to find work in the I.T. field
    ... I've applied for jobs such as Assistant Network ... There are people with degrees in Computer Science that can't ... some remote support person that can be half way around the world. ... I was getting paid to design micro-controllers and systems by ...
    (alt.computer.security)
  • Re: Relationships. Does anyone use them?
    ... more overhead in creating an app and unnecessary...or do you believe ... One of the basic precepts of relational database design is to have ... generally called constraints - I believe that is the term used in the ... of relationship so the relationships window is clean of tables. ...
    (comp.databases.ms-access)
Loading