Re: Why all the max length constraints?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 28 May 2006 03:46:16 GMT
Message-ID: <c29eg.13908$A26.329809_at_ursa-nb00s0.nbnet.nb.ca>
>> Marshall wrote:
>>
>>> dawn wrote:
>>>
>>>> [why all the length constraints?]
>>>
>>>
>>> You asked a very general question, so I'm going to respond in
>>> very general terms.
>>>
>>> Length constraints are a physical reality.
>>
>>
>>
>> Yes, the computer needs to allocate space somehow. Understood. I
>> don't tell it when I start a new Word document how much space to use,
>> but I might get a message that I'm out of space and not be able to save
>> it.
>>
>>
>>> Your computer is finite,
>>> and it can only take so much data before choking.
>>
>>
>>
>> Thanks, Marshall, but with explanations like that I'm worried that you
>> are buying into the Fox news spin on my intellect too ;-)
>>
>>
>>> And there are
>>> times when software is buggy and will write data forever, filling
>>> up your disk or dbms or whatever.
>>
>>
>>
>> Most assuredly
>>
>>
>>> It is best if the entire system
>>> not die under those circumstances.
>>
>>
>>
>> I knew I would learn something new from you ;-)
>>
>>
>>> (There are also times where
>>> such bad behavior is deliberate, as in denial-of-service attacks.)
>>> So no matter how it appears, there are real limits somewhere.
>>
>>
>>
>> Yes.
>>
>>
>>> Note that Java strings are conventionally referred to as variable
>>> length, but they are in fact a maximum of 2^31 characters long.
>>
>>
>>
>> I am only referring to logical variaibility, so I think of Java String
>> as logically having a similar spec to a Pick attribute. Are you
>> wishing that you had to put a max length on every declaration of a
>> variable of type String? I'm not.
>>
>>
>>> Realistically, if you have a field for state/province, and someone
>>> enters 6 megabytes of character data, something has gone wrong
>>> somewhere.
>>
>>
>>
>> Yes, and there should be no data entry widget that permits entry of
>> more than 2 characters for a state code, for example, more likely
>> selecting from a drop-down.
>>
>>
>>> Better to trap it around character 255 than to
>>> let it just run along sucking up resources.
>>
>>
>>
>> I do want the software product (as a whole) to limit anything which has
>> a conceptual limit.
>>
>>
>>> There is nothing specific to RM here.
>>
>>
>>
>> In the other response I gave, I asked questions related to how those
>> dbms systems where attributes have variable length seem to also be the
>> ones that do not have the unordered requirement of the RM.
>> set processing have anything to do with it? In other words, are you
>> sure that it is just a coincidence that all existing implementations
>> (flawed though they may be) of the RM work extensively with length
>> constraints
>> implement the RM (whether OO, XML, MV, MUMPS?...) are more inclined
>> toward variable lengths.
Date: Sun, 28 May 2006 03:46:16 GMT
Message-ID: <c29eg.13908$A26.329809_at_ursa-nb00s0.nbnet.nb.ca>
J M Davitt wrote:
> dawn wrote: >
>> Marshall wrote:
>>
>>> dawn wrote:
>>>
>>>> [why all the length constraints?]
>>>
>>>
>>> You asked a very general question, so I'm going to respond in
>>> very general terms.
>>>
>>> Length constraints are a physical reality.
>>
>>
>>
>> Yes, the computer needs to allocate space somehow. Understood. I
>> don't tell it when I start a new Word document how much space to use,
>> but I might get a message that I'm out of space and not be able to save
>> it.
>>
>>
>>> Your computer is finite,
>>> and it can only take so much data before choking.
>>
>>
>>
>> Thanks, Marshall, but with explanations like that I'm worried that you
>> are buying into the Fox news spin on my intellect too ;-)
>>
>>
>>> And there are
>>> times when software is buggy and will write data forever, filling
>>> up your disk or dbms or whatever.
>>
>>
>>
>> Most assuredly
>>
>>
>>> It is best if the entire system
>>> not die under those circumstances.
>>
>>
>>
>> I knew I would learn something new from you ;-)
>>
>>
>>> (There are also times where
>>> such bad behavior is deliberate, as in denial-of-service attacks.)
>>> So no matter how it appears, there are real limits somewhere.
>>
>>
>>
>> Yes.
>>
>>
>>> Note that Java strings are conventionally referred to as variable
>>> length, but they are in fact a maximum of 2^31 characters long.
>>
>>
>>
>> I am only referring to logical variaibility, so I think of Java String
>> as logically having a similar spec to a Pick attribute. Are you
>> wishing that you had to put a max length on every declaration of a
>> variable of type String? I'm not.
>>
>>
>>> Realistically, if you have a field for state/province, and someone
>>> enters 6 megabytes of character data, something has gone wrong
>>> somewhere.
>>
>>
>>
>> Yes, and there should be no data entry widget that permits entry of
>> more than 2 characters for a state code, for example, more likely
>> selecting from a drop-down.
>>
>>
>>> Better to trap it around character 255 than to
>>> let it just run along sucking up resources.
>>
>>
>>
>> I do want the software product (as a whole) to limit anything which has
>> a conceptual limit.
>>
>>
>>> There is nothing specific to RM here.
>>
>>
>>
>> In the other response I gave, I asked questions related to how those
>> dbms systems where attributes have variable length seem to also be the
>> ones that do not have the unordered requirement of the RM.
> > > Apples and oranges. > > Also, might >
>> set processing have anything to do with it? In other words, are you
>> sure that it is just a coincidence that all existing implementations
>> (flawed though they may be) of the RM work extensively with length
>> constraints
If one is going to interact with the self-aggrandizing ignorant, one need merely ask her to prove her assertion that "all existing implementations ... of the RM" require length constraints and leave it at that.
> This is certainly not the case. The concept of maximum length fields > has nothing to do with the relational model. Stop looking for > something that doesn't exist. > > while many of those (not all, for sure) that do not >
>> implement the RM (whether OO, XML, MV, MUMPS?...) are more inclined
>> toward variable lengths.
> > > There are, I"m sure, tens of thousands of products that "do not > implement the RM" in which field lengths are either fixed or > limited to a maximum.
And there are many SQL products that support fields with unconstrained field lengths regardless whether they do it well or poorly. Received on Sun May 28 2006 - 05:46:16 CEST