Re: Why all the max length constraints?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 28 May 2006 13:51:14 GMT
Message-ID: <mVheg.14053$A26.332608_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> 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.
>
>
>
>
> 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.
>
>
>
>
> 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?
>
>
>
>
> 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 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.
>
>
>
>
> Then please use terminology in a way consistent with the
> community here. Why do you refuse to do this?
>
>
>
>
> 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.
Date: Sun, 28 May 2006 13:51:14 GMT
Message-ID: <mVheg.14053$A26.332608_at_ursa-nb00s0.nbnet.nb.ca>
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. Received on Sun May 28 2006 - 15:51:14 CEST