Re: Why all the max length constraints?

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?

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

>

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?

> > 4) are unqualified to teach computer science anywhere

>

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

> 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?

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.

Personally, I doubt it has anything to do with RM specifically.

> Maybe it is just tradition, maybe it has to do with the
> data model avoiding all ordering of data,

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

> 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?

It's not that /every/ software /needs/ to be told constraints. It's that software /implementors/ can often implement more efficient solutions if they are given additional information (constraints).

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

You say you try very hard, yet you admit "[you] know ;-)" you were failing to do so. Inconsistent.

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

What matters in c.d.t I would think is not the "industry" as much as the c.d.t community consensus. Which you claim you already "know ;-)" so please use it.

> Did you fail to understand what I meant?

I was confused yes. It seemed to take longer than usual to understand.

> Do you have a better way for me to write it?

You claim to "know ;-)" the community consesus. Employing it would be satisfactory.

• Keith --