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.

That would be the reason for my question. I am asking what is the
reason that all of the implementations of the RM work with a max length
constraint on attributes. So I should have written "why couldn't the
DBMS...", perhaps, but most would understand the rhetorical technique,
I would think.

This is a classic example of argument from
ignorance or the burden of proof logical fallacy.

You seem to think I'm arguing something when I think I am asking
something.

And yet
you imply this fallacious claim from the start of the
thread. Do you understand this is a logical fallacy?

Honey, I'm just askin' a question based on an observation. If I knew
the answer, I would not ask. I am not intending to make a claim, other
than any that help me ask the question.

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.

No need to get jumpy. I am trying to figure out the source of this
common implementation trait in products that stem from the RM. What is
the reason for the max length constraints in products developed based
on work done with the RM? I honestly do not know the answer even after
reading your replies.

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.

Yes, but it would be foolish to think that every change to a product
would result in an increase in cost. Surely there are some that would
result in a decrease. So the only costs I could think of that would
always result in an increase were project costs.

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

This is totally misleading. /Runtime enforcement/ of
constraints /may/ reduce performance.

Thus the word "could"

However constraints by
themselves are performance neutral as clearly it depends on
how those constraints are implemented.

Yup.

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.

Indeed.

Furthermore, /knowledge/ of constraints allows increased
optimization

Now we are getting somewhere. Not every type of constraint with every
type of dbms would be helpful for optimization. So, what is it about
these implementations stemming from the RM that benefits from having
human beings specify these particular attribute max length constraints?
It very well might not be relevant to the RM at all. I simply don't
know and would like to.

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?

Yes.

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."

That is dated from when I filled in for a year, although I'm still on
the books for various reasons until August.

You are teaching computer science

"and mathematics" and it is "was" not "are"

and you "can't think of
any reason why MV systems would be faster if there were max
length constraints in the DBMS"???

Max length constraints on individual attributes. If somehow I implied
that I could not think of any reason it would be faster without
specifying any space-related information, then please adjust
accordingly as that was not my thinking.

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

And you do know why max length on _attributes_ would make Pick more
efficient?

4) are unqualified to teach computer science anywhere

I've claimed the latter before. I am not a computer scientist and have
told my students that. I'm a long-time practitioner in IT, with
degrees in Mathematics, not CS.

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.

Lots of not answering my question going on here.

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.

I have no answer I'm driving at, but am trying to understand. I have
worked from the user to the app-implementation of many varied "data
processing" systems, but have never written a DBMS tool. I do not have
enough understanding of what is under the covers of any dbms to know
what the reason would be for the max length constraints on attributes.
I've put out some guesses which could be completely wrong, but only to
help get the question out there.

WHAT I'M ASKING: I just want to know precisely what is drivng every
dbms vendor who is attempting to base their design on the RM to end up
putting these attribute max length constraints in while some who do not
base their model on the RM do not have them. Maybe it is just
tradition, maybe it has to do with the data model avoiding all ordering
of data, maybe every software product everywhere really needs to be
told by a human the individual max lengths for (4)each (4)value (3)for
(12)optimization (8)purposes. (Yes, that was irritating, but might
help make my question clearer) Do you know?

That this is what you /feel/ not think. that you are looking
not to learn but rather to have your prejudices reinforce
themselves.

You aren't getting me, brother. I'm in this forum to learn by asking
questions that I have, ones where I am ignorant (not lawyer questions
where I know the answer). If I want to persuade, other than to get my
questions through, I can do that elsewhere (my blog, for example). I
once had a "theory prejudice" for the RM, and then adopted a "practice
prejudice" for other models. I have not yet rectified these. Unlike
other softare developers who might have similar practice prejudices, I
am not writing off theory as irrelevant. I think it is relevant, so I
want to square these up, nudging the practices toward sound theory and
the theory toward best practices.

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 actually try very hard to do that. For some things there are no
common industry terms, or I am unaware of them, so I have to try to use
English to say what I'm trying to say. Did you fail to understand what
I meant? Do you have a better way for me to write it?

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.

Yes, my "no, no" meant that was not what I meant, so I restated it.

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").

I sure thought that I was using the terms "conceptual" and "logical" as
Pascal used them in his Unmuddling Modeling paper I bought (I'm his
customer ;-) and read a while back (I'll haul it out again and brush
up). He might have used "conceptual model" and "logical model" where
others (and I) use CDM and LDM.

What are you not understanding in my question. I'm addressing the
effort when going from a conceptual model for a new system (from a
requirements analysis phase of a project, for example) to a model that
can be directly entered into a DBMS (from a design phase). Please,
please tell me what terms you would use to ask that question.

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.

I could read numerous papers and learn enough so that I could produce
an implementation of the RM myself, at which point I would know why I
wanted those attribute length constraints. Alternatively, I could ask
the question figuring someone might already know enough to provide me
with a straight-forward response. Are all of the other questions in
cdt or all of the valid ones such that answers would not come from any
materials already written?

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.

I rather doubt that and I am not presupposing it. I'm asking.

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.

Again, you are not getting me. Maybe my writing style is getting in
the way. I am not attempting to market Pick in this forum at all, but
I have often used it as a counter-example when asking questions. I
have tried to reduce that, but if I asked this question with no counter
example, it would have been even harder to get my specific question
through, I think. I am trying to understand how to square up solid
theory and best practices based on what I have learned of each. I had
no idea how sensitive some would be when I started asking such
questions. The reaction of not answering questions but attacking the
questioner has been really surprising, prompting me to want to
understand what fortress was being protected and why it needed guns
instead of logic for responses.

If the answer to my question about max length constraints is one you
know, please try to explain it and I will try to understand your
response, possibly by asking follow up questions. Once I understand
the response, which perhaps everyone but me in this forum already
understands, then I'll be done with this question and can move on.

Thanks. --dawn

.

Relevant Pages

  • Re: Why all the max length constraints?
    ... Do you realize that even if no DBMS ... constraints /may/ reduce performance. ... Computer Science and Mathematics at Dordt." ... 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 ... constraints /may/ reduce performance. ... (in ways the conceptual model need not). ... mention separation between logical and physical design. ...
    (comp.databases.theory)
  • Re: OT Bull-fight avoidance (was: Why all the max length constraints?)
    ... DBMS, for example. ... The performance advantages of size constraints is ... developers have no choice ... often written prior to RM ideas getting incorporated into DBMS tools ...
    (comp.databases.theory)
  • 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)