Re: OT Bull-fight avoidance (was: Why all the max length constraints?)

Keith H Duggar wrote:
> dawn wrote:
> > Keith H Duggar wrote:
> > > dawn wrote:
> > > > I can't think of any reason why MV systems would be
> > > > faster if there were max length constraints in the
> > > > DBMS, for example.
> > >
> > > The performance advantages of size constraints is
> > > fundamental.
> >
> > I believe I clarified by saying that my question and
> > this statement were about the same thing -- max length
> > constraints on attribute values.
>
> > > I think any computer science curriculum would teach
> > > this. And thus isn't this something EVERY software
> > > development professional should know?
> >
> > That attributes specified to every type of DBMS must have
> > max length constraints for performance reasons? That DBMS
> > developers (those who write DBMS software) have no choice
> > but to write software that requires or performs
> > significantly better if there are max length constraints
> > on attributes?
>
> What the? Where are you getting this "must have", "no
> choice", "requires", "significantly" crap from?

>From my question. I wasn't sure I understood what you were saying in
response. Skip that and I'll give it one more try below.

> Nobody has
> said that. You are putting words into my mouth and creating
> a false dichotomy (yet another logical fallacy).

No, I'm trying to ask a question.

> Please stop
> Dawn. Have some respect for the time other people take to
> write and actually read what they wrote. Let me quote myself
> from /another/ post which you seem to have ignored.
>
> Keith H Duggar:
> > 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).

Yes. I understand that. What type of tuning is possible, required, or helpful depends on the design of the solution, correct? Do you agree that there are some, typically "legacy", database management systems, often written prior to RM ideas getting incorporated into DBMS tools where tuning, assisting, configuring or whatever is not related to specifying maximum length constraints on attributes? Clearly there are other means of improving performance, including sizes of one thing or another. [Most of these now have an implementation of SQL, and they might appear to be and likely claim to be relational. ]

Now, is it the case that all (maybe only most?) DBMS's that have been developed claiming from the outset they were relational, meeting the data independence requirement for example, have some optimization tied to max column length constraints? I don't know the answer to that. If the answer to this is "no" then I'm interested in which tools are "fine with" no such constraints being specified and that answers my question.

If the answer is "yes" then my question is why that might be. Is it the "serif" case or something else that might prompt a decision by the DBMS developers (those who write DBMS tools) to write the toolset in a way that makes these constraints of max column length something that users are rewarded for entering (and maybe users are even required to enter such in some cases)? This is what I'm seeking to understand.

So, I made an observation. I asked if my observation was accurate. If it is accurate, then what is the reason? I asked if there was anything about the RM that might prompt such implementations. The overwhelming response is 'no' but I'm still wondering whether it is then simply tradition or something else.

> This DIRECTLY answers those two question. Do you see the
> "not ... every ... needs", "can often", "more efficient"?
> Now do you see how rude your "must have", "no choice",
> "requires", and "significantly" sophistry is?

No, but I definitely apologize if I was rude. I am clearly having a hard time stating this question in a way that you can understand. If you shed any notion that I'm trying to offend (I'm not) and instead try to figure out what my obviously flawed questions are trying to ask, perhaps you could meet me half way on this. I would like to be able to get all the way to questions that would resonate with you, but I'm clearly having trouble doing that.

> > Are you absolutely sure that hash tables with attribute
> > values in delimited strings would perform better if there
> > were individual max length constraints for each individual
> > attribute, for example?
>
> To be honest I'm not sure what you mean by "hash tables with
> attribute values in delimited strings". Maybe you mean a
> "hash index OF delimited string values".

No, I don't think so. I'm not in areas I know much about when talking about the implementation details of a DBMS, but one DBMS that uses hash tables for implementation where developers do not specify max length constraints when defining an attribute (so optimization is done in other ways) is described in

http://www.fitzlong.com/Technical%20Papers.htm

> > Does it depend on the implementation of the DBMS as to
> > whether those particular constraint specifications provide
> > much, if any, assist to the performance?
>
> Yes of course it depends on the implementation. And thus to
> analyze it further we need to be more concrete and code up
> an implementation.

Why? There are already many existing ones. I'm wondering why they made the decisions they did, again, if my observation is accurate (that DBMS's with variable length attributes as the norm are not ones that stem from attempts to implement the RM from the outset). For example, do ideas about "columns" being unordered or data independence end up prompting implementation approaches that make the max-length-on-columns the best of many options? Or is one company just following the next in using this strategy so it is just tradition for DBMS companies that think they are writing an RDBMS products?

> In any case, I now know this is quite
> off-topic here so we should not discuss this in cdt any
> longer.

It would be nice to get an answer, but if I'm not going to get one here, so be it.

> Perhaps you should open a thread in comp.programming
> to discuss the general advantages of fixed-length data.

I don't have such a question. It is very easy (for me) to find information on that topic.

> > How many times must I do that. I will definitely admit
> > that I did not before I wrote this and do not now
> > understand why a DBMS must be written so that max length
> > constraints on attributes are important for its
> > performance.
>
> Stop it Dawn! More of this "must" and "important" crap false
> dichotomy.

If you understand my question then please adjust it so it reads as you would have wanted to write it. If you don't understand my question, then don't assume the worst.

> > I think I have even seen a counter-example.
>
> Yes, false dichotomy and sophistry is useful in this way.

Maybe if we could figure out how to connect up with each other on this topic, wars would cease, so that is why I'm persistent. I do suspect there is at least one reader who is understanding both my questions and your reactions and is finding this to be very entertaining. I'm clearly frustrated and you seem to think I'm doing something amiss on purpose.

> > [can] you tell me if and why those implementing DBMS's
> > that stem from the RM either tend to or always write the
> > DBMS tools so that it is advantageous for optimization to
> > know the individual max lengths of the attributes?
>
> As to "if" I have no idea.

Woo Hoo -- that was an answer to one part of my question. Your answer was "I have no idea" but it at least gives me hope that you understand that part of the question.

> As to "why" how can one ever know
> the motivations of another?

There are some on this list who have worked on RDBMS's products, others who have a lot more insight into their design than I. It is a legitimate question to ask what the tradeoffs are and why a particular design decision is made in any existing product, including software products. You might not know the answer, and we are not going to get every single piece of history in the decision-making process for every existing "relational database" on the table, but some might have helpful insights and opinions on the matter.

> I would suggest asking them (the
> implementors) or checking for technical papers documenting
> their design choices.

I did a little of that, but it would take me quite some time to get the answer to the question that way, I suspect.

> Now I can speculate that they /allow/
> users to specify constraints both for conceptual and logical
> usefulness AND for the usual performance benefits that
> additional KNOWLEDGE (in this case of size) might allow. And
> again this has nothing to do with RM specifically. Rather it
> is just the usual /computer/ implementation (of anything)
> issues and trades.

OK, which still leaves me wondering why there are some not-originally-implementing-the-RM products with the variable-length as the norm and it doesn't seem to be a similar mix in the attempts at RM implementation. (and I really hope I am not using offensive language)

>
> > Is it a correct observation and, if so, do you know why it
> > is the case that DBMS's developed from other models are
> > more likely to (but certainly don't always) provide tools
> > where the specification of a max length on individual
> > attributes is not (as) important?
>
> I have no experience with DBMS products.

What does this mean? I'll assume it doesn't mean what it seems to say.  If you really "have no experience with DBMS products" that definitely could explain why we are having trouble communicating!

> Others have stated
> this is simply a hallucination. Do you have any DATA on the
> matter?

I only know that when I have used Oracle, MySQL, PostgreSQL, and when I have read SQL Server information (I gave it a spin a long, long time ago) the examples I have seen and the tables I have worked with use such constraints. I also recall that when we were taking a system developed with variable lengths, we either had to go through and set a maximum on each attribute in order to generate Oracle tables or we did so unnecessily. I assume the former at the time and was not the person who researched it.

> (Wait, I just recalled I used FileMaker Pro quite a bit some
> years ago.

Good, then I am correct that your statement about having no experience with DBMS products must mean something else, such as the construction of a DBMS tool (with which I also have no experience).

> I NEVER input any size constraints. Is FileMaker
> an RDBMS? If so does this demolish your generalization?)

I have not used FileMaker. From my recollection this would synch with what recall from the early 80's. Based on my vague memory on the topic, I suspect this is an example of a DBMS tool developed with a "pre-relational mindset" but would be happy to hear otherwise. If I had a counter example, I would have my answer.

> dawn wrote:
> > Keith H Duggar wrote:
> > > mAsterdam wrote:
> > > > I have recently refrained from asking questions
> > > > revealing ignorance because of
> > >
> > > Perhaps your hesitancy has more to do with personal
> > > pride?
> >
> > I no not what I'm hesitant about nor what I'm prideful
> > about.
>
> [snip response from DW to a question NOT addressed to DW]
>
> Did I somehow screw up my quoting? My question was addressed
> to mAsterdam NOT you, Dawn. Why are you responding to it as
> if it was addressed to you?

No, I screwed up on that one. Sorry. --dawn Received on Mon May 29 2006 - 08:24:21 CEST