Re: Why all the max length constraints?

J M Davitt wrote:

> dawn wrote:
> 

> 
> Restrict it to one or two characters, obviously.  Wouldn't you?
> 


>>>> Thanks for any insights into database attribute length constraints,


>>>> their purpose (is it related to output with fixed fonts, database

>>>> performance, size or what?), and any correlation to implementations

>>>> (again, however flawed) of the RM,

The self-aggrandizing ignorant knows nothing of any other aspect of database management either. Doesn't the above admission strike everyone as redundant?

   I have
>> this idea that possibly the fact that everything in XML, Pick, and
>> elsewhere is ordered gives them more of a likelihood of permitting
>> variable length and handling it well since you can tag-delimit values.

So, the self-aggrandizing ignorant doesn't know anything about the topic but "has an idea that" somehow extremely primitive text file formats and file processors have some advantage due to order. Can anyone think of a better example of blind faith?

And the moron assumes those who dismiss her for her stupidity and ignorance do so on religious grounds.

>> Is there possibly something about how RDBMS's would need to allocate
>> space for columns or something that might make it advantageous for
>> there to be a max length?

No, that's not relevant. The R in RDBMS is purely logical and imposes no such limitations. Lazy-assed programmers introduce size limitations to make their jobs easier. That has nothing to do with the logical data model (not that the self-aggrandizing ignorant has a clue what one of those is.)

     The other thought I had was that working
>> with sets and joins might mean that implementing with everything
>> variable length could be problematic for allocation of space somehow,
>> but I (obviously) don't know.

Obviously.

>>> if there is such. 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?

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

Yes.

   If so, why hasn't anyone done
>> so?

Prove that nobody has done so. Even MS Access and Dbase III have binary and text fields of unlimited length.

  It seems it would help with the goal of decoupling the physical
>> from the logical. If there is no conceptual reason for a limit,
>> couldn't the dbms take care of such physical issues?

Yes, of course.

> This is not what others are referring to when they mention separation > between logical and physical design.

It is and it isn't. Certainly, one would prefer to separate physical restrictions and considerations from logical restrictions and considerations.

>> I'm looking right now at all of the aspects of a conceptual design that
>> need to be adjusted in what I was calling the logical (data) design
>> (the one implemented by means of a person or program interfacing with
>> the DBMS) and how such designs are done differently using the RM (or an
>> implementation thereof, however flawed) or MV.

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