Re: Why all the max length constraints?
Date: 28 May 2006 05:50:43 -0700
Message-ID: <1148820643.568997.273590_at_u72g2000cwu.googlegroups.com>
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.
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?
> 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.
> 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 Received on Sun May 28 2006 - 14:50:43 CEST