Re: Why all the max length constraints?
Date: Sun, 28 May 2006 23:37:49 GMT
Message-ID: <hvqeg.14245$A26.338051_at_ursa-nb00s0.nbnet.nb.ca>
Keith H Duggar wrote:
> dawn wrote:
>
>>You seem to think I'm arguing something when I think I am >>asking something.
>
>
>>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.
>
>
>>I have no answer I'm driving at, but am trying to understand.
>
>
> versus
>
>
>>[I] adopted a "practice prejudice" for other models.
>
>
>>I want to ... nudg[e] the practices toward sound theory >>and the theory toward best practices.
>
>
> "I am an advocate of the data model underlying the MV
> databases." -- dawn
>
> "Funny, but that is precisely why I advocate for a graph
> model over a strictly relational model." -- dawn
>
> So which is it, Dawn? Are you open and seeking to learn and
> understand? Or are you prejudiced and advocating and trying
> to nudge others around?
We already know the answer to those questions. We have known for at least three years. Dawn lacks intellectual honesty and intellectual capacity.
>>>>>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.
>
> Of course it would be foolish to think that! And neither I
> nor JMD suggested it. What JMD tried to explain was that you
> raised an equally naive requirement
>
> "Could a vendor write an implementation of the RM where
> length constraints are as rare as they are in the
> conceptual model without introducing performance or any
> other issues?"
>
> "... without introducing performance or any other issues"
> being the part that is naive/foolish.
>
>>>>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"
>
> Thus the word /misleading/ instead of /false/. "could" only
> prevented it from being plainly /false/. It was juxtaposing
> run-time and constraint while not mentioning enforcement vs
> knowledge that was misleading, as I tried to explain. Since
> you agree (snip yes, yup, etc) with the points I raised, let
> us just leave it with a suggestion. When skirting well trod
> territory step precisely lest you enter the mine field.
>
>
>>Max length constraints on individual attributes.
>
> What else would we apply "max length constraints" to besides
> attributes?? The max cardinality of tuples? of relations?
> Honestly I was only thinking of 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.
>
> No need to adjust because I have no idea what /other/
> space-related information you were talking about besides
> attribute values.
>
>
>>And you do know why max length on _attributes_ would make >>Pick more efficient?
>
> Is Pick a DBMS? Any DBMS running on any hardware available
> today (that I can think of) can benefit from knowledge of
> size constraints. Even allowing only string attributes, then
> I can think of /numerous/ efficiency benefits to specifying
> size constraints on the strings. Hence the suggestion you
> study string implementations because there is a rich history
> and wealth of information available. Another example is
> specifying range constraints on numerical values. /Numerous/
> optimizations there as well.
>
>
>>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.
>
> By the way I apologize to c.d.t I realize this is probably
> way off-topic. It seems we are discussing domain support (if
> I understand the term correctly), physical implementation
> etc. Is that off-topic here?
> Dawn, did you take a look at some string implementations? Or
> are you asking someone to walk you through an example of how
> constraints can optimize a particular domain? I could take
> you through such an example but I'm afraid it's off-topic?
And it would not benefit her in the least. Self-aggrandizing ignorants do not seek to learn no matter how hard they pretend to. Just like sociopaths learn to mimic emotional responses, the VI and other trolls learn to mimic the reactions of sincere students of the topic when it suits them for keeping the pointless discussion going. The only purpose is to generate so much nonsense that most people won't read the details closely enough to realise just how stupid and ignorant the VI is and will instead leave with the impression that the troll had something relevant to say.
>>>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. >>... >>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'm not trying to be mean; this explains a lot. Truly you
> have said a number of provocative things in the past many of
> which would make experts cringe. In other words, ignorance
> was shining brightly (ignorance of certain things I mean).
> Now there is nothing wrong with ignorance; but, we have to
> have humility and not be vociferous and provocative. In so
> far as database theory goes I'm ignorant too. Only came here
> a few weeks ago. Yet the archives and the few discussions
> I've been involved with were very informative. So I think
> this community is generally willing to teach those willing
> to learn.
>
>
>>Maybe my writing style is getting in the way.
>
> I think that is the case. Perhaps not so much your style of
> writing as your style of "thinking".
It's not style but content that's the problem. The self-aggrandizing ignorants are masters at writing stylish gibberish.
>>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.
No, Dawn, you would not. You have already read the material that explains exactly why forced attribute length constraints have absolutely nothing to do with the relational model. It does not require reading numerous papers, and having read the material, you have demonstrated your own profound incapacity to comprehend.
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?
Dawn has received that straightforward answer a dozen times already and she proved herself completely impervious to it.
> Alternatively, you could ask questions with humility and be
> vigilant in recognizing your areas of ignorance.
>
>
>>I've put out some guesses which could be completely wrong, >>but only to help get the question out there.
>
> Be careful when "put[ing] out some guesses". It's usually
> not necessary, might not "help [to] get the question out",
> and in your case is often provocative.
>
>
>>I'm [Fabian Pascal's] customer
>
> Congratulations! Still driving an FUV?
>
>
>>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.
We have already explained ad nauseum that Dawn's basic premise, the fundamental axiom behind her question is demonstrably false. Reiterating the axiom only further proves her stupidity--and we did not need any additional proof.
> Personally, I doubt it has anything to do with RM
> specifically.
It doesn't have anything to do with it at all.
>>Maybe it is just tradition, maybe it has to do with the >>data model avoiding all ordering of data,
Maybe it is not even a fact but an hallucination of her feeble little mind.
> First, order is not "avoided". Rather physical order is
> simply not part of the data model. I can't see how this
> choice has any effect on size constraints. Also, since we
> are talking about domain value constraints, it seems this
> nothing to do the relational model which treats domain
> values as atomic (if I understand correctly).
[The remainder of this absolute waste of time snipped.] Received on Mon May 29 2006 - 01:37:49 CEST