Why all the max length constraints?

[dawn]

[OK, here is my next "stupid question" as I cut a path in my study of
the RM. Those teachers who just want to tell this student how ignorant
she is are welcome to sit this out as I really am hoping to
understand.]

In SQL-DBMS's, like VSAM (and other indexed sequential files before
them) a lot of attributes are specified with max length constraints.
While there are some attributes where this constraint is related to a
conceptual constraint (from the analysis phase), these lengths are
often introduced for the logical model or implemenation in the DBMS.

In other words, when mapping from the conceptual (analysis) to the
logical (design) data models (pick the terms you like best for these),
these constraints are designed for many attributes that have no such
conceptual/business limits (if implemented with a paper system, there
would be no such limit, for example).

Is there something about the RM that would prompt all (or most?)
existing implementations (however flawed) to drive developers to add in
these constraints for performance, space saving, or other reasons? I
realize there can be variable length attributes, but specifying a max
field length still seems to be the norm (is that still the case?)

As many of you know, I work with database management systems that treat
all data as variable in length, while one might specify a length for
display purposes.

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

TIA. --dawn

[Marshall]

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. Your computer is finite,
and it can only take so much data before choking. And there are
times when software is buggy and will write data forever, filling
up your disk or dbms or whatever. It is best if the entire system
not die under those circumstances. (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.
Note that Java strings are conventionally referred to as variable
length, but they are in fact a maximum of 2^31 characters long.

Realistically, if you have a field for state/province, and someone
enters 6 megabytes of character data, something has gone wrong
somewhere. Better to trap it around character 255 than to
let it just run along sucking up resources.

There is nothing specific to RM here.

Marshall

[J M Davitt]

dawn wrote:
> [OK, here is my next "stupid question" as I cut a path in my study of
> the RM. Those teachers who just want to tell this student how ignorant
> she is are welcome to sit this out as I really am hoping to
> understand.]

[Quiz time: what are scalars, tuples, and relations?]

> In SQL-DBMS's, like VSAM (and other indexed sequential files before
> them) a lot of attributes are specified with max length constraints.

I don't mean to pick nits, but I don't grok "VSAM" and SQL-DBMS's.

IIRC, VSAM provided for an OCCURS-like construction in record layouts -
but all that meant was that you could have a variable number of fields,
all of fixed width, up to some specified maximum. MicroData, Pick,
Progress, &c, mean very different things when they describe things as
variable.

> While there are some attributes where this constraint is related to a
> conceptual constraint (from the analysis phase), these lengths are
> often introduced for the logical model or implemenation in the DBMS.
>
> In other words, when mapping from the conceptual (analysis) to the
> logical (design) data models (pick the terms you like best for these),
> these constraints are designed for many attributes that have no such
> conceptual/business limits (if implemented with a paper system, there
> would be no such limit, for example).
>
> Is there something about the RM that would prompt all (or most?)
> existing implementations (however flawed) to drive developers to add in
> these constraints for performance, space saving, or other reasons?

No.

> I
> realize there can be variable length attributes, but specifying a max
> field length still seems to be the norm (is that still the case?)

Yes.

> As many of you know, I work with database management systems that treat
> all data as variable in length, while one might specify a length for
> display purposes.

I can't imagine that it's useful for 'Smith, Joseph' and 'Smith, John'
to appear as identical values when, say, displayed in a field of eight
characters. I also work with products where all data are of variable
length. (There is a maximum, but it's huge.) PITA. This mis-feature
accounts for a fair number of support calls.

> 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 issue has nothing to do with the relational model.

[dawn]

J M Davitt wrote:
> dawn wrote:
> > [OK, here is my next "stupid question" as I cut a path in my study of
> > the RM. Those teachers who just want to tell this student how ignorant
> > she is are welcome to sit this out as I really am hoping to
> > understand.]
>
> [Quiz time: what are scalars, tuples, and relations?]

You define scalar and I'll define tuples and relations.
btw, I think my def of relation is already in the cdt dictionary.

> > In SQL-DBMS's, like VSAM (and other indexed sequential files before
> > them) a lot of attributes are specified with max length constraints.
>
> I don't mean to pick nits, but I don't grok "VSAM" and SQL-DBMS's.

It is not a nit pick for you to point out things you don't fully
understand.

> IIRC, VSAM provided for an OCCURS-like construction in record layouts -
> but all that meant was that you could have a variable number of fields,
> all of fixed width, up to some specified maximum.

Indexed sequential files were a natural progression from cards. It is
easy to see how fixed lengths arose out of working with card decks. I
wondering if the concept was simply never dropped or had a reason for
continuing.

> MicroData, Pick,
> Progress, &c, mean very different things when they describe things as
> variable.

The first two should mean the same if you are referring to MicroData
Reality. There are some good stories on the splitting of ways between
Dick Pick and Don Fuller, but yes, I'm sure that "variable" is used for
different things.

> > While there are some attributes where this constraint is related to a
> > conceptual constraint (from the analysis phase), these lengths are
> > often introduced for the logical model or implemenation in the DBMS.
> >
> > In other words, when mapping from the conceptual (analysis) to the
> > logical (design) data models (pick the terms you like best for these),
> > these constraints are designed for many attributes that have no such
> > conceptual/business limits (if implemented with a paper system, there
> > would be no such limit, for example).
> >
> > Is there something about the RM that would prompt all (or most?)
> > existing implementations (however flawed) to drive developers to add in
> > these constraints for performance, space saving, or other reasons?
>
> No.
>
> > I
> > realize there can be variable length attributes, but specifying a max
> > field length still seems to be the norm (is that still the case?)
>
> Yes.
>
> > As many of you know, I work with database management systems that treat
> > all data as variable in length, while one might specify a length for
> > display purposes.
>
> I can't imagine that it's useful for 'Smith, Joseph' and 'Smith, John'
> to appear as identical values when, say, displayed in a field of eight
> characters.

Obviously not if truncated. The default with Pick would be to wrap in
any display. This is usually good, but has its own issues too, of
course. For every solution...

> I also work with products where all data are of variable
> length. (There is a maximum, but it's huge.) PITA. This mis-feature
> accounts for a fair number of support calls.

What is the best mitigation strategy in your case? If you know that an
attribute must have no more than two characters, what do you do?

> > 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 issue has nothing to do with the relational model.

I know nothing of how dbms products are designed internally. 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.

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

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

Is your answer to this question "yes"? If so, why hasn't anyone done
so? 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?

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.

Thanks for your help. --dawn

[dawn]

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

--dawn

[J M Davitt]

dawn wrote:
> J M Davitt wrote:
>
>>dawn wrote:
>>
>>>[OK, here is my next "stupid question" as I cut a path in my study of
>>>the RM. Those teachers who just want to tell this student how ignorant
>>>she is are welcome to sit this out as I really am hoping to
>>>understand.]
>>
>>[Quiz time: what are scalars, tuples, and relations?]

It's a quiz. These are fundamental terms in the relational model.

> You define scalar and I'll define tuples and relations.
> btw, I think my def of relation is already in the cdt dictionary.
>
>
>>>In SQL-DBMS's, like VSAM (and other indexed sequential files before
>>>them) a lot of attributes are specified with max length constraints.
>>
>>I don't mean to pick nits, but I don't grok "VSAM" and SQL-DBMS's.
>
>
> It is not a nit pick for you to point out things you don't fully
> understand.

Okay, let's be explicit: what do SQL and VSAM have to do with each
other?

>
>>IIRC, VSAM provided for an OCCURS-like construction in record layouts -
>>but all that meant was that you could have a variable number of fields,
>>all of fixed width, up to some specified maximum.
>
>
> Indexed sequential files were a natural progression from cards. It is
> easy to see how fixed lengths arose out of working with card decks. I
> wondering if the concept was simply never dropped or had a reason for
> continuing.

Fine. But off-point. Isn't it true that the variable in VSAM means
a range of fixed-width fields?

>
>
>>MicroData, Pick,
>>Progress, &c, mean very different things when they describe things as
>>variable.
>
>
> The first two should mean the same if you are referring to MicroData
> Reality. There are some good stories on the splitting of ways between
> Dick Pick and Don Fuller, but yes, I'm sure that "variable" is used for
> different things.

And doesn't their use of the term variable differ from the use of the
term in VSAM? And don't you want to clear this up before moving
forward? After all, you tossed VSAM and "all data as variable in
length" into the discussion about fixed-width attributes. (Or, more
precisely, you used the phrase "max length constraints."

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 issue has nothing to do with the relational model.
>
>
> I know nothing of how dbms products are designed internally. 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.
>
>
> 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? 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.

But, you know, there is always a "max length." It may be a large
value, but it's there. IIRC, 32K is common in the products I cited
in my earlier post. Can you verify that?

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

>
> Is your answer to this question "yes"? If so, why hasn't anyone done
> so? 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?

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

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

[J M Davitt]

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

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.

>
> --dawn
>

[dawn]

Definitely. I would have expected the other to be the case too - that
some implementations of the RM had fixed or max lengths and others did
not. But they all seem to use the same strategy in this regard. Since
they all implement some variety of SQL, is there anything about SQL
that would require this approach? I'm definitely not looking for
something, I'm trying to understand. Thanks. --dawn

[Bob Badour]

J M Davitt wrote:
> dawn wrote:
>
>> [OK, here is my next "stupid question" as I cut a path in my study of
>> the RM. Those teachers who just want to tell this student how ignorant
>> she is are welcome to sit this out as I really am hoping to
>> understand.]

What I find ignorant and stupid is the suggestion that field constraints
have anything to do with the relational model, which places no
restrictions on data types. If the self-aggrandizing ignorant had
bothered to educate herself on the fundamentals instead of pursuing some
idiotic agenda by comparing the flaws of seriously flawed products, she
would realise this already.

>> 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 issue has nothing to do with the relational model.
>
> 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?
>> TIA. --dawn

The fact that the self-aggrandizing ignorant confused logical and
physical with every word she speaks comes as no surprise.

[dawn]

J M Davitt wrote:
> dawn wrote:
> > J M Davitt wrote:
> >
> >>dawn wrote:
> >>
> >>>[OK, here is my next "stupid question" as I cut a path in my study of
> >>>the RM. Those teachers who just want to tell this student how ignorant
> >>>she is are welcome to sit this out as I really am hoping to
> >>>understand.]
> >>
> >>[Quiz time: what are scalars, tuples, and relations?]
>
> It's a quiz. These are fundamental terms in the relational model.

Yes, I know. Why do you think I could not define them? I've provided
definitions, likely for each of these, for the glossary at one time or
another, along with defs for "functions" which are relations.

I have read quite a bit about the RM (including TTM and almost all of
Date's 8e). My questions are typically about topics not covered in
such places and are all about the application and usefulness of the
theory related to databases. They stem from having had a belief that
the RM was the way to go and then seeing how much more bang for the
buck at least one non-RM-database model was for a company. So, I'm
trying to square up what I've learned in the real world with the theory
that has driven the database industry for the past couple of decades.
There is still a gap, but I'm understanding a bit more where the
implementations of the RM have taken the industry a bit astray from
what I have seen as best practices (2VL, LVAs, variable length
variables, for example).

> > You define scalar and I'll define tuples and relations.
> > btw, I think my def of relation is already in the cdt dictionary.
> >
> >
> >>>In SQL-DBMS's, like VSAM (and other indexed sequential files before
> >>>them) a lot of attributes are specified with max length constraints.
> >>
> >>I don't mean to pick nits, but I don't grok "VSAM" and SQL-DBMS's.
> >
> >
> > It is not a nit pick for you to point out things you don't fully
> > understand.
>
> Okay, let's be explicit: what do SQL and VSAM have to do with each
> other?

Developers using each include max lengths in the metadata, given them
both that good old computer card feel where you list the attributes in
some order (recognizing order is different for cards and vsam than for
sql-dbms's) with their lengths (and types) when defining your schema.
It almost make me want to add a Hollerith code, length of 1, of course.

> >>IIRC, VSAM provided for an OCCURS-like construction in record layouts -
> >>but all that meant was that you could have a variable number of fields,
> >>all of fixed width, up to some specified maximum.
> >
> >
> > Indexed sequential files were a natural progression from cards. It is
> > easy to see how fixed lengths arose out of working with card decks. I
> > wondering if the concept was simply never dropped or had a reason for
> > continuing.
>
> Fine. But off-point. Isn't it true that the variable in VSAM means
> a range of fixed-width fields?

There can be an OCCURS clause (in COBOL) for cardinality > 1 and there
can also be fields of arity > 1, so we lost both of those features with
SQL, but otherwise it was just defining a virtual card, which could be
> 80 columns once it wasn't read in or written to an actual card. The following is from memory and I haven't coded COBOL since 88, but it was something like

01 PERSON.
03 PERSON_ID PIC X(9).
03 NAME.
05 FIRST_NAME PIC X(15).
05 LAST_NAME PIC X(20).
03 GENDER PIC X.
03 AGE PIC 999.

Which might become
CREATE TABLE PERSON
PERSON_ID CHAR(9),
FIRST_NAME CHAR(15),
LAST_NAME CHAR(20),
GENDER CHAR(1),
AGE INT(3);

The changes for the SQL table were the removal of attributres with
higher cardinality or arity than 1 and the idea that the order was not
important. Otherwise, these look rather similar and unlike languages
where you need not define a max length for every variable. IBM played a
major role with both too, which might also be irrelevant.

> >>MicroData, Pick,
> >>Progress, &c, mean very different things when they describe things as
> >>variable.
> >
> >
> > The first two should mean the same if you are referring to MicroData
> > Reality. There are some good stories on the splitting of ways between
> > Dick Pick and Don Fuller, but yes, I'm sure that "variable" is used for
> > different things.
>
> And doesn't their use of the term variable differ from the use of the
> term in VSAM? And don't you want to clear this up before moving
> forward? After all, you tossed VSAM and "all data as variable in
> length" into the discussion about fixed-width attributes. (Or, more
> precisely, you used the phrase "max length constraints."

I'm not sure what is not clear. I used the term "max length
constraints" so that it was clear what I meant by variable length
(being the opposite where there are no such maximum length constraints
on the data values). Sorry I'm not understanding your question. Did
this clear it up?

Yup, so what's the problem that becomes a PITA and what makes it
difficult to correct or mitigate it to avoid the support calls?

> >
> >>>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 issue has nothing to do with the relational model.
> >
> >
> > I know nothing of how dbms products are designed internally. 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.
> >
> >
> > 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? 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.
>
> But, you know, there is always a "max length." It may be a large
> value, but it's there.

Yes, understood. My question is about the logical data model (pick
your favorite name for it) -- the definition of the schema to the
computer. Why give a max length to an attribute that doesn't
conceptually require such? Why can't the DBMS handle that for you
(efficiently, of course)?

> IIRC, 32K is common in the products I cited
> in my earlier post. Can you verify that?
>
> >>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.

I'm referring to run-time issues. Of course there would be a cost to
change a product. At run-time, fewer constraints could be a
performance boost. I can't think of any reason why MV systems would be
faster if there were max length constraints in the DBMS, for example.
Your answer makes me think there is something about the way RM
implementations (or approximations thereof) operate that is enhanced by
knowing how many card columns are required, thereby prompting
developers to specify this physical design and limit the implementation
unnecessarily (in ways the conceptual model need not).

> > Is your answer to this question "yes"? If so, why hasn't anyone done
> > so? 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?
>
> This is not what others are referring to when they mention separation
> between logical and physical design.

I know ;-)

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

No, no, I'm mapping the conceptual model for the purpose of
implementation. The conceptual model, the business requirements, might
not have a limit on the size of a color attribute, for example, but
then in the "implementation model" or what I and others have called the
"logical data model" we add in a length of 12 characters, for example.

Did that help clarify? --dawn

[Bob Badour]

J M Davitt wrote:

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.
>
>> Is your answer to this question "yes"?

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.

[Bob Badour]

J M Davitt wrote:

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.

[Keith H Duggar]

dawn wrote:
> J M Davitt wrote:
> > But, you know, there is always a "max length." It may
> > be a large value, but it's there.
>
> Yes, understood. My question is about the logical data
> model (pick your favorite name for it) -- the definition
> of the schema to the computer. Why give a max length to
> an attribute that doesn't conceptually require such? Why
> can't the DBMS handle that for you (efficiently, of
> course)?

Who says they cannot? Do you realize that even if no DBMS
implementation has yet done so, this is not evidence of
impossibility. This is a classic example of argument from
ignorance or the burden of proof logical fallacy. And yet
you imply this fallacious claim from the start of the
thread. Do you understand this is a logical fallacy?

Furthermore, as others have pointed out already and in other
contexts, implying that deficiencies in DBMS products imply
problems with the relational model is even more fallacious.

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

> At run-time, fewer constraints could be a performance
> boost.

This is totally misleading. /Runtime enforcement/ of
constraints /may/ reduce performance. However constraints by
themselves are performance neutral as clearly it depends on
how those constraints are implemented. Perhaps they are
implemented at compile time. Perhaps they are free on
particular hardware (integers modulo 2^32 on a 32-bit
machine for example). Etc. Etc.

Furthermore, /knowledge/ of constraints allows increased
optimization and hence a performance boost. It seems obvious
that one force behind this historical attraction to fixed
size domains is the easily obtained performance benefits.
Let us again note this has nothing to do with the relational
model. You know of course that ISAM (part of your original
topic) predates the RM? And isn't ISAM basically synonymous
(historically) with fixed length records?

> I can't think of any reason why MV systems would be faster
> if there were max length constraints in the DBMS, for
> example.

Ok, I'm sorry but this ... this seems absurd. I cannot
rectify your statement with this quote from your (this is
you correct?) Dordt bio:

"I have been an Information Technology professional for
more than a quarter of a century and now have my own
business. I am taking time off from that to teach
Computer Science and Mathematics at Dordt."

You are teaching computer science and you "can't think of

any reason why MV systems would be faster if there were max

length constraints in the DBMS"??? These are basic, core,
fundamental issues here. Either you

1) are joking
2) are exaggerating
3) don't "feel" like taking a moment to think
4) are unqualified to teach computer science anywhere

Seriously which is it, Dawn? If you truly meant what you
said then may I suggest you forget about data models, DBMS,
relations, etc for a time and focus simply on scalars and
domains. Specifically, please examine the history and
current art of implementing strings. From examning string
implementations alone you will learn a great deal about
time/space/abstraction/constraint costs/tradeoffs etc. Then
you will have no trouble "think[ing] of ... reason[s] why MV
systems would ..."

> Your answer makes me think there is something about the
> way RM implementations (or approximations thereof) operate
> that is enhanced by knowing how many card columns are
> required, thereby prompting developers to specify this
> physical design and limit the implementation unnecessarily
> (in ways the conceptual model need not).

Your posts make me think this is what you /want/ to believe.
That this is what you /feel/ not think. that you are looking
not to learn but rather to have your prejudices reinforce
themselves.

> > 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'm looking right now at all of the aspects of a

> > > conceptual design that need to be adjusted ...

> >
> > 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.
>
> No, no, I'm mapping the conceptual model for the purpose
> of implementation. The conceptual model, the business
> requirements, might not have a limit on the size of a
> color attribute, for example, but then in the
> "implementation model" or what I and others have called
> the "logical data model" we add in a length of 12
> characters, for example.

No, no, you said you were looking into "adjusting" the
/conceptual/ design. Then you both contradicted and agreed
with JMDs point that you do not "adjust" the /conceptual/
design you implement it! Or perhaps in your words "adjust"
the "mapping" (or dawn-called "logical model").

Look, if you honestly want to learn about why many DBMS
implementations gravitate toward size constraints, is it
really so hard to find out? There must be papers, reports,
books, etc that examine and discuss various implementation
choices.

Perhaps you are right and there is something beyond the
usual, typical, basic design tradeoffs (that any computer
science teacher should know). Something special and unique
to RM. Something buried deep in the bowls of corporate
archives. Something hidden. Something profound. Something
that Codd knew and tried to hide. Something that confirms
the supremacy of Pick's genius. Go forth Dawn! Find it! Do
the research and blind us all with a dawning of new light.

-- Keith ---

[mAsterdam]

dawn wrote:
> [OK, here is my next "stupid question" as I cut a path in my study of
> the RM. Those teachers who just want to tell this student how ignorant
> she is are welcome to sit this out as I really am hoping to
> understand.]
>
> In SQL-DBMS's, like VSAM (and other indexed sequential files before
> them) a lot of attributes are specified with max length constraints.

To really answer any question relating to this we'ld have
to operationalize this observation by establishing what to
compare with ("a lot") and by counting max length/non-max
length attributes at a significant number of sites using
different solutions for data-sharing, and ...
Oops we don't have the resources to do so.

My hunch is that you are right.
("a lot" interpreted as more than in the delivered
conceptual models).

> While there are some attributes where this constraint is related to a
> conceptual constraint (from the analysis phase), these lengths are
> often introduced for the logical model or implemenation in the DBMS.
>
> In other words, when mapping from the conceptual (analysis) to the
> logical (design) data models (pick the terms you like best for these),
> these constraints are designed for many attributes that have no such
> conceptual/business limits (if implemented with a paper system, there
> would be no such limit, for example).
>
> Is there something about the RM that would prompt all (or most?)
> existing implementations (however flawed) to drive developers to add in
> these constraints for performance, space saving, or other reasons? I
> realize there can be variable length attributes, but specifying a max
> field length still seems to be the norm (is that still the case?)

Did you ever see COBOL programs from the early days?
Many of them were assembly programs crunched into COBOL syntax.
Builders rely on what they know works.

A related notion: form survives function.
Look at those little bars in 'serif' fonts: when you cut out
characters in stone or wood, you first make a little bar in order
to prevent splicing their media when they carve the big bar.
They needed the little bars (serifs).
Many files on mainframes initially had a recordlength of 80 - why?
Cars started like coaches without horses.

> As many of you know, I work with database management systems that treat
> all data as variable in length, while one might specify a length for
> display purposes.

In a way of speaking they dropped the serif for storage purposes,
but not for display purposes.

> Thanks for any insights into database attribute length constraints,
> their purpose (is it related to output with fixed fonts, database
> performance, size or what?),

When there is a real, practical reason for adopting
some attribute max length - think of external (outgoing)
interfaces - the max length should be in the conceptual
model.

> and any correlation to implementations
> (again, however flawed) of the RM, if there is such.

The explanation along the above lines would be carry-over:
The early adapters had a lot of max-length
limitations in theire existing solutions.

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

The length contraints are specified by the designers of the
database, not by the designers of the dbms.

[mAsterdam]

Well, then. If you agree with the observation,
what is your explanation?

[mAsterdam]

J M Davitt wrote:
> dawn wrote:

>> [OK, here is my next "stupid question" as I cut a path in my study of
>> the RM. Those teachers who just want to tell this student how ignorant
>> she is are welcome to sit this out as I really am hoping to
>> understand.]

[snip]

>> Is there something about the RM that would prompt all (or most?)
>> existing implementations (however flawed) to drive developers to add in
>> these constraints for performance, space saving, or other reasons?
>
> No.
>
>> I realize there can be variable length attributes,
>> but specifying a max field length still seems to be the
>> norm (is that still the case?)
>
> Yes.

Checking OT-ness: Beyond what was specified in the conceptual model.

Why do you think this is so? (I gave one explanation in immediate
reply to the OP, but I'ld be glad to see other explanations).

>> As many of you know, I work with database management systems that treat
>> all data as variable in length, while one might specify a length for
>> display purposes.
>
>
> I can't imagine that it's useful for 'Smith, Joseph' and 'Smith, John'
> to appear as identical values when, say, displayed in a field of eight
> characters. I also work with products where all data are of variable
> length. (There is a maximum, but it's huge.) PITA. This mis-feature
> accounts for a fair number of support calls.

Oops! I can imagine that. So in the product you work with you can't even
hav a max-length attributes even if they /are/ in the conceptual model
?! What product is that?

[snip]

[mAsterdam]

dawn wrote:
> Marshall wrote:
>>dawn wrote:
>>>[why all the length constraints?]

[snip]

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

If the state code fields (*) in the database are defined
as having 2 characters, there is a efective max-length
constraint of 2. Now it doesn't matter wether there is
a data entry widget that permits entry of more than 2
characters for a state code. The data in the the database
is garantueed to not violate this specific constraint.

Another constraint set/type (ISO country-codes) would
be tighter, of course, and the user interface could
well be more sophisticated by using them.

(*) Not phrased in RM terms to show that this
is a general database issue, not RM specific.

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

This is a reason to put the conceptual limits as
close to the data as possible. If they are enforced in
the database the rest of the software product
has to follow suit. Any other way isn't
garantueed, is it?

>>There is nothing specific to RM here.

[snip]

[Tony Andrews]

dawn wrote:
> J M Davitt wrote:

> > 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.
>
> Definitely. I would have expected the other to be the case too - that
> some implementations of the RM had fixed or max lengths and others did
> not. But they all seem to use the same strategy in this regard. Since
> they all implement some variety of SQL, is there anything about SQL
> that would require this approach? I'm definitely not looking for
> something, I'm trying to understand. Thanks. --dawn

dawn wrote:

> J M Davitt wrote:
> > 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.
>
> Definitely. I would have expected the other to be the case too - that
> some implementations of the RM had fixed or max lengths and others did
> not. But they all seem to use the same strategy in this regard. Since
> they all implement some variety of SQL, is there anything about SQL
> that would require this approach? I'm definitely not looking for
> something, I'm trying to understand. Thanks. --dawn

Can we assume that by now, thanks to answers from various people here,
you will accept that "no, there is NOT anything about SQL that would
require this approach?" Somehow I doubt it. Most (if not all) SQL
DBMSs have an "unlimited" character type (in Oracle for example it is
called CLOB. Of course there is an ultimate limit: something like 2GB
IIRC).

Perhaps one could mischeviously suggest that the people who who use SQL
DBMSs are more sophisticated than the people who use MV databases, and
so more clearly understand the benefits of placing constraints on
columns.

Here is one benefit. Suppose you are building a client application
that interacts with a database. For example, it allows you to read
information about an employee into the application and display it on
screen for possible update. Imagine how much easier that is if you
know that emp_name is limited to 100 chars, and job_title to 50 (or
whatever). You know you are not going to have to provide unlimited
memory to store 1,000,000-character names, nor apply a substring
function to cut such rogue data down to something more manageable. In
fact, you don't actually need to "know" how big those columns are at
all - the application can find out from the database and allocate
memory accordingly, with minimal danger of using up all the memory on
the machine.

But my main concern is this, Dawn: do you now acknowledge that there is
nothing in SQL, let alone the RM, that /requires/ this approach?

[David Cressey]

"dawn" <dawnwo...@gmail.com> wrote in message
news:1148773922.2...@j55g2000cwa.googlegroups.com...

I don't think it's a stupid question.

Back when I was first getting adjusted to DEC Rdb/VMS, I noticed that COBOL
programmers tended to prefer fixed length fields (yes, fields) for
everything, while BASIC programmers tended to prefer variable length
character strings. Not surprising, since that is how their programming
language trained them to think. Later on, when I switched over to Oracle, I
noticed that Oracle designers tended to use VARCHAR2 in placed where I would
have used CHAR.

In part that's driven by different performance characteristics of Oracle and
Rdb (at that time). In part it's a cultural difference.

I think the specification of a MAX for variable length strings is a
performance oriented feature, rather than a logical feature.
I believe that a system could operate entirely without upper limits on data
block size. I have designed a set of data blocks that work like this, but
I haven't yet put it to the test.

The more interesting question is whether variable length is a feature of the
problem domain or of the solution domain. That gets to be an interesting
question when a database is being designed as a subsystem of a larger
system. In the data architecture of the larger system, the choice for
fixed length fields may be made for reasons that pertain to the solution
domain rather than the problem domain.

From the perspective of the database designer, the data architecture of the
larger system is part of the problem domain. There are exceptions to this,
when the architect of the database can influence the data architecture of
the larger system.

[mAsterdam]

Bob Badour wrote:
> J M Davitt wrote:
>
>> dawn wrote:
>>
>>> [OK, here is my next "stupid question" as I cut a path in my study of
>>> the RM. Those teachers who just want to tell this student how ignorant
>>> she is are welcome to sit this out as I really am hoping to
>>> understand.]

Good thing that J M David quoted this.

> What I find ignorant and stupid

You can read, but all this wonderful knowledge goes to
waste if you don't try to get the message.

Stop it.

You are hurting people.

You are discouraging people to contribute /questions/
to this group. Real questions show ignorance and
the willingness to explore it.

> is the suggestion that field constraints
> have anything to do with the relational model, which places no
> restrictions on data types. If the self-aggrandizing ignorant had
> bothered to educate herself on the fundamentals instead of pursuing some
> idiotic agenda by comparing the flaws of seriously flawed products, she
> would realise this already.

You can write. Some toes will be stepped upon in
discussion - that can't be helped. Please excersize
your writing skills to prevent unnecessarily hurting
people and still point out what you think is wrong.

Your postings look as if you are deliberately
inflicting damage at the cost of any possibly
sensible topic.

Please stop it.

[David Cressey]

"Marshall" <marshal...@gmail.com> wrote in message
news:1148775197.1...@y43g2000cwc.googlegroups.com...

It's possible to design schemes for variable length data that is
indefinitely extensible. The familiar decimal numbers are one such scheme.
Within such schemes, it's possible to design schemes that are reasonably
concise at the low end, and add only trivial amounts of overhead at the high
end. Within such concise schemes, it's possible to design schemes that
are more robust than ones that depend on separator characters, as some
systems do. I'm exploring whether it's worthwhile to do so.

You are right. There is nothing specific to the RM here.

[David Cressey]

"dawn" <dawnwo...@gmail.com> wrote in message

news:1148787091.3...@j55g2000cwa.googlegroups.com...

>
> J M Davitt wrote:
> > dawn wrote:
> > > J M Davitt wrote:
> > >
> > >>dawn wrote:
> > >>
> > >>>[OK, here is my next "stupid question" as I cut a path in my study of
> > >>>the RM. Those teachers who just want to tell this student how
ignorant
> > >>>she is are welcome to sit this out as I really am hoping to
> > >>>understand.]
> > >>
> > >>[Quiz time: what are scalars, tuples, and relations?]
> >
> > It's a quiz. These are fundamental terms in the relational model.
>
> Yes, I know. Why do you think I could not define them? I've provided
> definitions, likely for each of these, for the glossary at one time or
> another, along with defs for "functions" which are relations.
>

JMD may have joined the group since the time you did that. I think you
could save everybody a lot of time by just answering the quiz. It shouldn't
be too much of a burden, if you've answered these questions before.

[mAsterdam]

mAsterdam wrote:

> ... Good thing that J M David quoted this.

Sorry, J M Davitt.

[dawn]

Keith H Duggar wrote:
> dawn wrote:
> > J M Davitt wrote:
> > > But, you know, there is always a "max length." It may
> > > be a large value, but it's there.
> >
> > Yes, understood. My question is about the logical data
> > model (pick your favorite name for it) -- the definition
> > of the schema to the computer. Why give a max length to
> > an attribute that doesn't conceptually require such? Why
> > can't the DBMS handle that for you (efficiently, of
> > course)?
>
> Who says they cannot? Do you realize that even if no DBMS
> implementation has yet done so, this is not evidence of
> impossibility.

That would be the reason for my question. I am asking what is the
reason that all of the implementations of the RM work with a max length
constraint on attributes. So I should have written "why couldn't the
DBMS...", perhaps, but most would understand the rhetorical technique,
I would think.

> This is a classic example of argument from
> ignorance or the burden of proof logical fallacy.

You seem to think I'm arguing something when I think I am asking
something.

> And yet
> you imply this fallacious claim from the start of the
> thread. Do you understand this is a logical fallacy?

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.

> Furthermore, as others have pointed out already and in other
> contexts, implying that deficiencies in DBMS products imply
> problems with the relational model is even more fallacious.

No need to get jumpy. I am trying to figure out the source of this
common implementation trait in products that stem from the RM. What is
the reason for the max length constraints in products developed based
on work done with the RM? I honestly do not know the answer even after
reading your replies.

> > > 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. So the only costs I could think of that would
always result in an increase were project costs.

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

> However constraints by
> themselves are performance neutral as clearly it depends on
> how those constraints are implemented.

Yup.

> Perhaps they are
> implemented at compile time. Perhaps they are free on
> particular hardware (integers modulo 2^32 on a 32-bit
> machine for example). Etc. Etc.

Indeed.

> Furthermore, /knowledge/ of constraints allows increased
> optimization

Now we are getting somewhere. Not every type of constraint with every
type of dbms would be helpful for optimization. So, what is it about
these implementations stemming from the RM that benefits from having
human beings specify these particular attribute max length constraints?
It very well might not be relevant to the RM at all. I simply don't
know and would like to.

> and hence a performance boost. It seems obvious
> that one force behind this historical attraction to fixed
> size domains is the easily obtained performance benefits.
> Let us again note this has nothing to do with the relational
> model. You know of course that ISAM (part of your original
> topic) predates the RM? And isn't ISAM basically synonymous
> (historically) with fixed length records?

Yes.

> > I can't think of any reason why MV systems would be faster
> > if there were max length constraints in the DBMS, for
> > example.
>
> Ok, I'm sorry but this ... this seems absurd. I cannot
> rectify your statement with this quote from your (this is
> you correct?) Dordt bio:
>
> "I have been an Information Technology professional for
> more than a quarter of a century and now have my own
> business. I am taking time off from that to teach
> Computer Science and Mathematics at Dordt."

That is dated from when I filled in for a year, although I'm still on
the books for various reasons until August.

> You are teaching computer science

"and mathematics" and it is "was" not "are"

> and you "can't think of
> any reason why MV systems would be faster if there were max
> length constraints in the DBMS"???

Max length constraints on individual 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.

> These are basic, core,
> fundamental issues here. Either you
>
> 1) are joking
> 2) are exaggerating
> 3) don't "feel" like taking a moment to think

And you do know why max length on _attributes_ would make Pick more
efficient?

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

> Seriously which is it, Dawn? If you truly meant what you
> said then may I suggest you forget about data models, DBMS,
> relations, etc for a time and focus simply on scalars and
> domains.

Lots of not answering my question going on here.

> Specifically, please examine the history and
> current art of implementing strings. From examning string
> implementations alone you will learn a great deal about
> time/space/abstraction/constraint costs/tradeoffs etc. Then
> you will have no trouble "think[ing] of ... reason[s] why MV
> systems would ..."
>
> > Your answer makes me think there is something about the
> > way RM implementations (or approximations thereof) operate
> > that is enhanced by knowing how many card columns are
> > required, thereby prompting developers to specify this
> > physical design and limit the implementation unnecessarily
> > (in ways the conceptual model need not).
>
> Your posts make me think this is what you /want/ to believe.

I have no answer I'm driving at, but am trying to understand. I have
worked from the user to the app-implementation of many varied "data
processing" systems, but have never written a DBMS tool. 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've put out some guesses which could be completely wrong, but only to
help get the question out there.

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. Maybe it is just
tradition, maybe it has to do with the data model avoiding all ordering
of data, 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?

> That this is what you /feel/ not think. that you are looking
> not to learn but rather to have your prejudices reinforce
> themselves.

You aren't getting me, brother. I'm in this forum to learn by asking
questions that I have, ones where I am ignorant (not lawyer questions
where I know the answer). If I want to persuade, other than to get my
questions through, I can do that elsewhere (my blog, for example). I
once had a "theory prejudice" for the RM, and then adopted a "practice
prejudice" for other models. I have not yet rectified these. Unlike
other softare developers who might have similar practice prejudices, I
am not writing off theory as irrelevant. I think it is relevant, so I
want to square these up, nudging the practices toward sound theory and
the theory toward best practices.

> > > 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. 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. Did you fail to understand what
I meant? Do you have a better way for me to write it?

> > > > I'm looking right now at all of the aspects of a
> > > > conceptual design that need to be adjusted ...
> > >
> > > 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.
> >
> > No, no, I'm mapping the conceptual model for the purpose
> > of implementation. The conceptual model, the business
> > requirements, might not have a limit on the size of a
> > color attribute, for example, but then in the
> > "implementation model" or what I and others have called
> > the "logical data model" we add in a length of 12
> > characters, for example.
>
> No, no, you said you were looking into "adjusting" the
> /conceptual/ design.

Yes, my "no, no" meant that was not what I meant, so I restated it.

> Then you both contradicted and agreed
> with JMDs point that you do not "adjust" the /conceptual/
> design you implement it! Or perhaps in your words "adjust"
> the "mapping" (or dawn-called "logical model").

I sure thought that I was using the terms "conceptual" and "logical" as
Pascal used them in his Unmuddling Modeling paper I bought (I'm his
customer ;-) and read a while back (I'll haul it out again and brush
up). He might have used "conceptual model" and "logical model" where
others (and I) use CDM and LDM.

What are you not understanding in my question. I'm addressing the
effort when going from a conceptual model for a new system (from a
requirements analysis phase of a project, for example) to a model that
can be directly entered into a DBMS (from a design phase). Please,
please tell me what terms you would use to ask that question.

> Look, if you honestly want to learn about why many DBMS
> implementations gravitate toward size constraints, is it
> really so hard to find out? There must be papers, reports,
> books, etc that examine and discuss various implementation
> choices.

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?

> Perhaps you are right and there is something beyond the
> usual, typical, basic design tradeoffs (that any computer
> science teacher should know). Something special and unique
> to RM. Something buried deep in the bowls of corporate
> archives. Something hidden. Something profound.

I rather doubt that and I am not presupposing it. I'm asking.

> Something
> that Codd knew and tried to hide. Something that confirms
> the supremacy of Pick's genius. Go forth Dawn! Find it! Do
> the research and blind us all with a dawning of new light.

Again, you are not getting me. Maybe my writing style is getting in
the way. I am not attempting to market Pick in this forum at all, but
I have often used it as a counter-example when asking questions. I
have tried to reduce that, but if I asked this question with no counter
example, it would have been even harder to get my specific question
through, I think. I am trying to understand how to square up solid
theory and best practices based on what I have learned of each. I had
no idea how sensitive some would be when I started asking such
questions. The reaction of not answering questions but attacking the
questioner has been really surprising, prompting me to want to
understand what fortress was being protected and why it needed guns
instead of logic for responses.

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. Once I understand
the response, which perhaps everyone but me in this forum already
understands, then I'll be done with this question and can move on.

Thanks. --dawn

[dawn]

As soon as I understand why those max length constraints on attributes
are part of every such implementation, then I will have learned the
answer to my question and will be satisfied.

> Somehow I doubt it. Most (if not all) SQL
> DBMSs have an "unlimited" character type (in Oracle for example it is
> called CLOB. Of course there is an ultimate limit: something like 2GB
> IIRC).

Yes, I've worked with clobs (not exactly a satisfying experience IIRC,
perhaps in conjunction with odbc). So my question would be something
like a COB as the standard means of defining a string, for example.

> Perhaps one could mischeviously suggest that the people who who use SQL
> DBMSs are more sophisticated than the people who use MV databases,

I've used both ;-)

> and
> so more clearly understand the benefits of placing constraints on
> columns.
>
> Here is one benefit. Suppose you are building a client application
> that interacts with a database. For example, it allows you to read
> information about an employee into the application and display it on
> screen for possible update.

I knew someone had to tell me that it was easier to display. I can
definitely understand that if we are printing actual paper checks using
courier of a fixed size then we have only so many characters we can
print. If that is all this is about, then we need it far less today
than we once did and we should be very careful when we decide to put
that constraint on the database rather than determining how to handle
the representation. If another piece of data should be collected on
how to abbreviate the actual value in case of less space, fine. If it
is not a form like that, but simply a report, then wrap the data,
rather than truncating it, and you can have full values in fixed length
output. Again, that is a representation issue.

> Imagine how much easier that is if you
> know that emp_name is limited to 100 chars, and job_title to 50 (or
> whatever). You know you are not going to have to provide unlimited
> memory to store 1,000,000-character names, nor apply a substring
> function to cut such rogue data down to something more manageable. In
> fact, you don't actually need to "know" how big those columns are at
> all - the application can find out from the database and allocate
> memory accordingly, with minimal danger of using up all the memory on
> the machine.

If the reason these DBMS's do this is for me, the app developer, then
thanks, but I prefer not to use that feature when the data values are
conceptually of unlimited length.

> But my main concern is this, Dawn: do you now acknowledge that there is
> nothing in SQL, let alone the RM, that /requires/ this approach?

As soon as I understand it (which I did not before asking the
question), then I surely will acknowledge that if that is my
understanding. I'm getting closer. It surely is not the RM on its own
that requires such constraints. While I do understand why defining a
computer card layout requires lengths, I don't know why this data model
compared to others would require it, but, again, that's why I asked the
question. Thanks. --dawn

[dawn]

mAsterdam wrote:
> dawn wrote:
> > Marshall wrote:
> >>dawn wrote:
> >>>[why all the length constraints?]
>
> [snip]
> >>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.
>
> If the state code fields (*) in the database are defined
> as having 2 characters, there is a efective max-length
> constraint of 2. Now it doesn't matter wether there is
> a data entry widget that permits entry of more than 2
> characters for a state code. The data in the the database
> is garantueed to not violate this specific constraint.
>
> Another constraint set/type (ISO country-codes) would
> be tighter, of course, and the user interface could
> well be more sophisticated by using them.
>
> (*) Not phrased in RM terms to show that this
> is a general database issue, not RM specific.

Yes. You are saying that if the data type is a state, then you want to
define it as a state to the DBMS so that the typing can be enforced. I
understand that. But even in cases where there is no conceptual max on
a value (last name, for example), a max length is chosen for the
attribute definition to the dbms.

> >>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.
>
> This is a reason to put the conceptual limits as
> close to the data as possible. If they are enforced in
> the database the rest of the software product
> has to follow suit. Any other way isn't
> garantueed, is it?

Nothin' is guaranteed, mAsterdam, I undertsand your point. I'll just
say that if there is such a constraint, then the overall solution must
enforce that one way or another, over time, optimizing integrity,
maintainability, etc. I'll otherwise sidestep your question as it
might relate to my latest blog entry on constraints, and I understand
I've only addressed a tiny piece of the puzzle and there is much more
that could be said regarding cases where there are business rules to be
enforced.

For this question, I'm interested in cases where there is no such
conceptual constraint.

> >>There is nothing specific to RM here.

It sounds unanimous so far. I'm still left to guess precisely why what
are sometimes called RDBMS's are implemented this way, while others
might not be. Possible answers have been: 1) it has to do with the
representation of the data, helping developers not have to truncate or
decide how to abbreviate if they don't have enough space in some input
or output document. 2) it helps for optimization.

I was aware of the benefits and problems of 1). I was guessing 2) was
the case, but would like to better understand why the implementations
are such that these individual numbers help enough to require them
(except with clogs, and it would be practical to implement an Oracle
solution with all strings declared as clogs) while in other
implementations they are not deemed important enough to require. It
might just be tradition, but in any case, I'd like to understand
better.

Thanks. --dawn

[Bob Badour]

Or, then again, we could just blame Hollerith for fixed length fields.
Oh wait, maybe that's the same thing? Or should we blame Jacquard? Or
maybe de Vaucanson? Or even Falcon?

One might as usefully rant against the evils of EBCDIC as the evils of
fixed length fields.

> Perhaps you are right and there is something beyond the
> usual, typical, basic design tradeoffs (that any computer
> science teacher should know). Something special and unique
> to RM. Something buried deep in the bowls of corporate
> archives. Something hidden. Something profound. Something
> that Codd knew and tried to hide. Something that confirms
> the supremacy of Pick's genius. Go forth Dawn! Find it! Do
> the research and blind us all with a dawning of new light.

Dawn teaches at Dordt or is she a student? I suppose either way it is
much less suprising that she cannot distinguish science from religion.
After all, Dordt is a religious school that refers to Darwin's theories
of natural and sexual selection as "evolutionism" and refers to
"Christian and non-Christian approaches" to science as if religious
faith has any bearing whatsoever on the scientific method.

If she pretended to teach anything to anybody there, I would suggest the
students demand their tuition back; except, the sort of people who pay
for a degree from that sort of institution probably got exactly what
they wanted.

[J M Davitt]

I had added the pop quit to my response after finishing what
appeared later. The reason? Well, if you knew what scalars,
tuples, and relations were, you would be able to answer your
own question: there is nothing in the definitions of these
that, in any way, limits the size of stored data.

As for "implementations of the RM [that] have taken the industry
a bit astray:" should we understand that you think that some
implementation of the relational model used something other than
two-valued logic? That list-valued attributes - if I understand
the abbreviation - represent a "best practice?" That variable
length variables - let alone variable variables - have somewhere
been left behind?

Please, tell us exactly, which implementations of the relational
model have done this?

[snip]

[Tony Andrews]

dawn wrote:
> As soon as I understand why those max length constraints on attributes
> are part of every such implementation, then I will have learned the
> answer to my question and will be satisfied.

You mean: why do all SQL DBMSs /allow/ you to constrain the max length
of an attribute? You know they do not /force/ you to. I would see
this as just making a very commonly wanted data constraint easy to
define - i.e. rather than making you do this:

CREATE TABLE emp
( emp_name VARCHAR
, ...
, CONSTRAINT emp_name_length CHECK (LENGTH(emp_name) <= 100)
);

Of course, for people like yourself who don't see the point of database
constraints anyway, it confers no advantages.

> Yes, I've worked with clobs (not exactly a satisfying experience IIRC,
> perhaps in conjunction with odbc). So my question would be something
> like a COB as the standard means of defining a string, for example.

It can be, if you so choose.

> > Perhaps one could mischeviously suggest that the people who who use SQL
> > DBMSs are more sophisticated than the people who use MV databases,
>
> I've used both ;-)

Then I should have said "prefer" instead of "use"!

> I knew someone had to tell me that it was easier to display.

Probably because we've had this conversation before, a couple of years
ago.

I can
> definitely understand that if we are printing actual paper checks using
> courier of a fixed size then we have only so many characters we can
> print. If that is all this is about, then we need it far less today
> than we once did and we should be very careful when we decide to put
> that constraint on the database rather than determining how to handle
> the representation. If another piece of data should be collected on
> how to abbreviate the actual value in case of less space, fine. If it
> is not a form like that, but simply a report, then wrap the data,
> rather than truncating it, and you can have full values in fixed length
> output. Again, that is a representation issue.

I wasn't talking about paper, I was talking about programming and
memory.

> If the reason these DBMS's do this is for me, the app developer, then
> thanks, but I prefer not to use that feature when the data values are
> conceptually of unlimited length.

So don't. Use them when data values are of conceptually limited
length.

> > But my main concern is this, Dawn: do you now acknowledge that there is
> > nothing in SQL, let alone the RM, that /requires/ this approach?
>
> As soon as I understand it (which I did not before asking the
> question), then I surely will acknowledge that if that is my
> understanding. I'm getting closer. It surely is not the RM on its own
> that requires such constraints.

This is extremely frustrating - no wonder some posters lose their cool!
As everyone keeps telling you: the RM *does not require such
constraints at all*. Why do you persist in saying it does (on its own
or otherwise?) A cursory reading of Date would show that the RM
imposes no limits on the type of data that can be stored, and you could
download a free copy of Oracle, SQL Server or whatever onto your PC and
verify that they allow you to create character data of no specified
length.

So why are you merely "getting closer" after all this time?

[dawn]

Yes. I didn't start writing them until '77, but maintained some very
old assembler-like code.

> Many of them were assembly programs crunched into COBOL syntax.
> Builders rely on what they know works.
>
> A related notion: form survives function.

Yes, that was my reason for mentioning cards in one post. I needed
those fixed lengths when working with cards or anything that imitated
cards on disk. I don't now, although I do need specifications of
length for various representations. I would often prefer to store the
entire value, whatever its length might be now that I don't have card
columns to contend with.

> Look at those little bars in 'serif' fonts: when you cut out
> characters in stone or wood, you first make a little bar in order
> to prevent splicing their media when they carve the big bar.
> They needed the little bars (serifs).

I LOVE that tidbit -- thanks!

> Many files on mainframes initially had a recordlength of 80 - why?
> Cars started like coaches without horses.
>
> > As many of you know, I work with database management systems that treat
> > all data as variable in length, while one might specify a length for
> > display purposes.
>
> In a way of speaking they dropped the serif for storage purposes,
> but not for display purposes.

Very good.

> > Thanks for any insights into database attribute length constraints,
> > their purpose (is it related to output with fixed fonts, database
> > performance, size or what?),
>
> When there is a real, practical reason for adopting
> some attribute max length - think of external (outgoing)
> interfaces - the max length should be in the conceptual
> model.

Yes, although there could be considerable disagreement on what is
conceptual. If a single external interface can only accept 'n'
characters for a person's last name, wouldn't we still want to capture
the entire last name anyway? In the worst case we might also accept an
abbreviated version of the last name. Otherwise such workarounds as
putting in all last names, with some truncated for some purposes and
adjusting those that should not be truncated, would work. (My cousin
really does not like it that someone she deals with, it might be a bank
or credit card company, sends her important documents with a last name
of Westendorp-Ho instead of Westendorp-Holland -- I'm guessing that
someone named mAsterdam might appreciate that one. It would be a very
bad idea for the insitution not to have her actual name, however.

> > and any correlation to implementations
> > (again, however flawed) of the RM, if there is such.
>
> The explanation along the above lines would be carry-over:
> The early adapters had a lot of max-length
> limitations in theire existing solutions.

Yes, that that might be the whole of it, unless there is also some
efficiency issue that is necessary for this model and not others. It
sounds like that is not the case, but I don't yet understand what is.

> > 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?
>
> The length contraints are specified by the designers of the
> database, not by the designers of the dbms.

Right, but the feature of "wanting" such constraints is included by the
dbms designers. It is just the serif issue? I so, I'll suggest it is
time to make that which would ber analogous to sans-serif more common.
Thanks. --dawn

[mAsterdam]

dawn wrote:
> Keith H Duggar wrote:
>
>>dawn wrote:
>>

>>>... Why give a max length to

>>>an attribute that doesn't conceptually require such? Why
>>>can't the DBMS handle that for you (efficiently, of
>>>course)?
>>
>>Who says they cannot? Do you realize that even if no DBMS
>>implementation has yet done so, this is not evidence of
>>impossibility.

> That would be the reason for my question. I am asking what is the
> reason that all of the implementations of the RM work with a max length
> constraint on attributes. So I should have written "why couldn't the
> DBMS...", perhaps, but most would understand the rhetorical technique,
> I would think.

Even better:
"Why don't the DB designers let the DBMS handle it."
(Summary of my answer your OP: Because they trust
specifying it from earlier solutions.)

As soon as you say "can't" in relation to a pet tool or model
you are waving a red cloth in front of a bull.

Not unlike Neo's unfounded "prolog can't do this" or
"RM can't do that" statements repeated ad nauseam.

This gives room to responses like:

>>This is a classic example of argument from
>>ignorance or the burden of proof logical fallacy.
>
>
> You seem to think I'm arguing something when I think I am asking
> something.

You shouldn't have waved the red towel :-)

>>And yet
>>you imply this fallacious claim from the start of the
>>thread. Do you understand this is a logical fallacy?

[snip etc. etc.]

> I have no answer I'm driving at, but am trying to understand. I have
> worked from the user to the app-implementation of many varied "data
> processing" systems, but have never written a DBMS tool. 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.

Here you are suggesting again they aren't part of
the database design but part of the dbms.
They are not - another red towel. You could easily make
your statement in a way which shows you understand
that difference.

[snip]

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

The db designer determines attribute length constraints, not the dbms.
Why do you ignore this difference?

[snip]

[Bob Badour]

Tony Andrews wrote:

> dawn wrote:
>
>>>But my main concern is this, Dawn: do you now acknowledge that there is
>>>nothing in SQL, let alone the RM, that /requires/ this approach?
>>
>>As soon as I understand it (which I did not before asking the
>>question), then I surely will acknowledge that if that is my
>>understanding. I'm getting closer. It surely is not the RM on its own
>>that requires such constraints.
>
>
> This is extremely frustrating - no wonder some posters lose their cool!
> As everyone keeps telling you: the RM *does not require such
> constraints at all*. Why do you persist in saying it does (on its own
> or otherwise?) A cursory reading of Date would show that the RM
> imposes no limits on the type of data that can be stored, and you could
> download a free copy of Oracle, SQL Server or whatever onto your PC and
> verify that they allow you to create character data of no specified
> length.
>
> So why are you merely "getting closer" after all this time?

There's no stopping the invincibly ignorant. - DT

[Bob Badour]

Tony Andrews wrote:

> dawn wrote:
>
>>>But my main concern is this, Dawn: do you now acknowledge that there is
>>>nothing in SQL, let alone the RM, that /requires/ this approach?
>>
>>As soon as I understand it (which I did not before asking the
>>question), then I surely will acknowledge that if that is my
>>understanding. I'm getting closer. It surely is not the RM on its own
>>that requires such constraints.
>
>
> This is extremely frustrating - no wonder some posters lose their cool!
> As everyone keeps telling you: the RM *does not require such
> constraints at all*. Why do you persist in saying it does (on its own
> or otherwise?) A cursory reading of Date would show that the RM
> imposes no limits on the type of data that can be stored, and you could
> download a free copy of Oracle, SQL Server or whatever onto your PC and
> verify that they allow you to create character data of no specified
> length.
>
> So why are you merely "getting closer" after all this time?

There's no stopping the invincibly ignorant. - DT

(But apparently, on occasion, one can slow them down a little. Just a
little.)

[mAsterdam]

Hm... it's not what I said, but I can live whith it.

> I understand that.
> But even in cases where there is no conceptual max on
> a value (last name, for example), a max length is chosen for the
> attribute definition to the dbms.

"is chosen" by whom? Who made the choice?

>>>>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.
>>
>>This is a reason to put the conceptual limits as
>>close to the data as possible. If they are enforced in
>>the database the rest of the software product
>>has to follow suit. Any other way isn't
>>garantueed, is it?
>
> Nothin' is guaranteed, mAsterdam, I undertsand your point.

Your "there should be no data entry widget that permits entry of
more than 2 characters for a state code" tells me you have not
digested that understanding.

> I'll just say that if there is such a constraint,
> then the overall solution must enforce that one way or
> another, over time, optimizing integrity, maintainability, etc.
> I'll otherwise sidestep your question as it
> might relate to my latest blog entry on constraints, and I understand
> I've only addressed a tiny piece of the puzzle and there is much more
> that could be said regarding cases where there are business rules to be
> enforced.
>
> For this question, I'm interested in cases where there is no such
> conceptual constraint.
>
>>>>There is nothing specific to RM here.
>
> It sounds unanimous so far.

We can't have that, can we - should I introduce NOT NULL?
Nah :-)

> I'm still left to guess precisely why what
> are sometimes called RDBMS's are implemented this way, while others
> might not be.

Which ones? I am really not nitpicking that DB2, SQLserver, Oracle and
PostgreSQL aren't true R DBMS's.

> Possible answers have been: 1) it has to do with the
> representation of the data, helping developers not have to truncate or
> decide how to abbreviate if they don't have enough space in some input
> or output document. 2) it helps for optimization.
>
> I was aware of the benefits and problems of 1). I was guessing 2) was
> the case, but would like to better understand why the implementations
> are such that these individual numbers help enough to require them
> (except with clogs, and it would be practical to implement an Oracle
> solution with all strings declared as clogs) while in other
> implementations they are not deemed important enough to require. It
> might just be tradition, but in any case, I'd like to understand
> better.

It would help if you acknowledged that the designers
of the database have this reponsability, and not the
designers of the dbms.
They (the designers of the dbms) have the responsability to
provide facilities for the db designers to specify them,
and the facilities to enforce the specified constraints.

[Tony D]

Yes, it is a rather silly question. It's an almost impressively silly
question because if, as you've mentioned elsewhere, you've read TTM,
you should have seen stated in several different ways the assertion
that the relational model is orthogonal to the type system. A quick
Google found an interview (http://www.dbmsmag.com/int9410.html)
discussing an earlier version of the book, where Date says :

"The reason I say the ideas of object-oriented (at least the good ones)
are orthogonal to the ideas of the relational model is that *nowhere
does the relational model prescribe what data types you have*."

Unless the subtext was to have another tussle over the old "what's a
scalar type ?" question ...

If you're asking "why do (at least the majority) of SQL databases
require length constraints", then it's very probably to do with the way
those products chose to represent tables on disk. There may also be
"bleed" from other language designs into SQL - ISTR Joe Celko defending
the SQL types on the grounds that they were chosen to fit well with
existing programming languages in which SQL would be embedded (and in
passing applying a handbrake to any other language with a different
type system you might have the misfortune to want/need to use with an
SQL database).

- Tony

[Tony D]

Keith wrote :

> Your posts make me think this is what you /want/ to believe.
> That this is what you /feel/ not think. that you are looking
> not to learn but rather to have your prejudices reinforce
> themselves.

I may be being uncharitable, but by the tenor of Dawn's posts and of
what little I have read of her blog, I came to a similar conclusion
some time ago. This particular thread is so close to being a troll,
given that the premise it starts from is thoroughly discounted in at
least one of the books Dawn claims to have read, that I'm surprised it
has gathered as much steam as it has.

- Tony

[paul c]

J M Davitt wrote:
> dawn wrote:
>
>> J M Davitt wrote:
>>
>>> dawn wrote:
>>>

>>>> ...

This is a plea to stop this silly thread. Also to humbly point out to
those born after the fact that VSAM has as much to do with the various
RM's as Christianity does (that OCCURS stuff was in Cobol, not VSAM, in
fact VSAM had no notion of fields, just bytes and offsets).

magoo

[Kenneth Downs]

dawn wrote:

>
> In SQL-DBMS's, like VSAM (and other indexed sequential files before
> them) a lot of attributes are specified with max length constraints.

> While there are some attributes where this constraint is related to a
> conceptual constraint (from the analysis phase), these lengths are
> often introduced for the logical model or implemenation in the DBMS.
>

I think the question is clear enough, are fixed-length fields an intrinsic
requirement of the relational model?

Short answer: no.

But they are such a pervasive element of implemented systems that they may
appear to be a requirement, like the SQL language itself.

Going further, fixed widths are indefensible. RM seeks to separate
implemention details from data handling, therefore a fundamentalist mindset
would sooner or later fix on fixed-width fields as heretical.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

[Kenneth Downs]

Tony Andrews wrote:

>
> Here is one benefit. Suppose you are building a client application
> that interacts with a database. For example, it allows you to read
> information about an employee into the application and display it on
> screen for possible update. Imagine how much easier that is if you
> know that emp_name is limited to 100 chars, and job_title to 50 (or
> whatever). You know you are not going to have to provide unlimited
> memory to store 1,000,000-character names, nor apply a substring
> function to cut such rogue data down to something more manageable. In
> fact, you don't actually need to "know" how big those columns are at
> all - the application can find out from the database and allocate
> memory accordingly, with minimal danger of using up all the memory on
> the machine.
>

Hmmm, you know I might have said this myself before Dawn asked her question,
but now I wonder.

If an employee's name is more than 100 characters, then the constraint has
produced bad data, no? (though I'm not sure we've got a lot of Castillian
nobles in the databases these days) Perhaps a better display option would
be to indicate an exception condition, that there is a problem displaying
this particular employee? His name exceeds display area for this medium?

[dawn]

I can't. Somehow I ended up cut and pasting someting that truncated
"stated length" to "state" in two instances. Oops. (Maybe I was only
permitted 5 characters? ;-)

> > I understand that.
> > But even in cases where there is no conceptual max on
> > a value (last name, for example), a max length is chosen for the
> > attribute definition to the dbms.
>
> "is chosen" by whom? Who made the choice?

The application software designers in line with their users (not those
who wrote the dbms toolset, if that is the question)

> >>>>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.
> >>
> >>This is a reason to put the conceptual limits as
> >>close to the data as possible. If they are enforced in
> >>the database the rest of the software product
> >>has to follow suit. Any other way isn't
> >>garantueed, is it?
> >
> > Nothin' is guaranteed, mAsterdam, I undertsand your point.
>
> Your "there should be no data entry widget that permits entry of
> more than 2 characters for a state code" tells me you have not
> digested that understanding.

No, it tells you that I have not adopted it as my own opinion. I
understand, and do not write-off, your point. It still isn't mine,
however.

> > I'll just say that if there is such a constraint,
> > then the overall solution must enforce that one way or
> > another, over time, optimizing integrity, maintainability, etc.
> > I'll otherwise sidestep your question as it
> > might relate to my latest blog entry on constraints, and I understand
> > I've only addressed a tiny piece of the puzzle and there is much more
> > that could be said regarding cases where there are business rules to be
> > enforced.
> >
> > For this question, I'm interested in cases where there is no such
> > conceptual constraint.
> >
> >>>>There is nothing specific to RM here.
> >
> > It sounds unanimous so far.
>
> We can't have that, can we - should I introduce NOT NULL?
> Nah :-)
>
> > I'm still left to guess precisely why what
> > are sometimes called RDBMS's are implemented this way, while others
> > might not be.
>
> Which ones?

I seems like all the big ones are such that those using them seem to
always select max lengths, so I asked if it was the case and if so, why
those who wrote the DBMS did not make that optional without penalty (or
did some of them?)

> I am really not nitpicking that DB2, SQLserver, Oracle and
> PostgreSQL aren't true R DBMS's.
>
> > Possible answers have been: 1) it has to do with the
> > representation of the data, helping developers not have to truncate or
> > decide how to abbreviate if they don't have enough space in some input
> > or output document. 2) it helps for optimization.
> >
> > I was aware of the benefits and problems of 1). I was guessing 2) was
> > the case, but would like to better understand why the implementations
> > are such that these individual numbers help enough to require them
> > (except with clogs, and it would be practical to implement an Oracle
> > solution with all strings declared as clogs) while in other
> > implementations they are not deemed important enough to require. It
> > might just be tradition, but in any case, I'd like to understand
> > better.
>
> It would help if you acknowledged that the designers
> of the database have this reponsability, and not the
> designers of the dbms.

Yes, the database designers select max lengths, and the dbms designers
choose whether and how big a penalty would be if size were not
declared.

> They (the designers of the dbms) have the responsability to
> provide facilities for the db designers to specify them,
> and the facilities to enforce the specified constraints.

And the option to provide a feature permitting app or db designers not
to specify a size., the option to default to variable length unless
otherwise specified, for example.

Thanks! --dawn

[dawn]

paul c wrote:
> J M Davitt wrote:
> > dawn wrote:
> >
> >> J M Davitt wrote:
> >>
> >>> dawn wrote:
> >>>
> >>>> ...
>
> This is a plea to stop this silly thread.

Honest questions might seem silly until you understand. The purpose of
asking questions is to understand better. If you think it silly, then
you need not answer.

> Also to humbly point out to
> those born after the fact that VSAM has as much to do with the various
> RM's as Christianity does (that OCCURS stuff was in Cobol, not VSAM, in
> fact VSAM had no notion of fields, just bytes and offsets).

I was going to point that out but thought it was nitpicking to do so.
I simply redirected his point to COBOL instead. Perhaps it was not
necessary to specify lengths when working with VSAM, but I only saw it
done that way. From your description, it does sound like that was how
it operated (bytes and offsets), but if I got that wrong, thanks for
trying to correct it. --dawn

[dawn]

Tony D wrote:
> Keith wrote :
>
> > Your posts make me think this is what you /want/ to believe.
> > That this is what you /feel/ not think. that you are looking
> > not to learn but rather to have your prejudices reinforce
> > themselves.
>
> I may be being uncharitable, but by the tenor of Dawn's posts and of
> what little I have read of her blog, I came to a similar conclusion
> some time ago.

I obviously don't know how to ask questions. I try to make sure that
if my question is leading or misleading there is a dog-gone smiley
after it just to be sure it is not misinterpreted. I ask questions
where I don't know the answer and I try hard to get answers from what
is often a rash of insults.

Could you possibly be so kind as to point me to a more helpful group of
people who know relational theory as I have been working in the are of
data modeling and continue to bump into questions that I would like to
ask those who have different perspectives than mine. Asking seemed
like a good approach to learning how others think, how others
understand the topic, but I, too, am tiring of this approach to dialog
where I ask a question or give my perspective on something and then
there is a little group that feels a need to bash me on the head for
doing so.

Thankfully some like David, Marshall, JOG, x, mAsterdam, Jan and many
others do try to discuss the topics, but I'm sure they are tiring of
having so much noise in these discussions too. Why not answer
questions, participate in the discussion, or ignore the thread instead
of this approach? What is your purpose for particiipating in this
thread only to try to make this a discussion about me instead of the
question I asked?

> This particular thread is so close to being a troll,

hogwash

> given that the premise it starts from is thoroughly discounted in at
> least one of the books Dawn claims to have read,

I read 'em, but didn't memorize 'em, feel free to point me to a page
number that answers my question.

> that I'm surprised it
> has gathered as much steam as it has.

Maybe it is a reasonable question to ask and maybe there is a good
reasonable response. Maybe you know the good reasonable response and
have decided not to offer it and trash me instead, or maybe you don't
know the response either in which case we could both learn something
from the thread. This is SOOOOO frustrating I could scream! --dawn

[mAsterdam]

dawn wrote:
> mAsterdam wrote:
>>dawn wrote:
>>>mAsterdam wrote:
>>>>dawn wrote:
>>>>>Marshall wrote:
>>>>>>dawn wrote:
>>>>>>
>>>>>>>[why all the length constraints?]

>>>... even in cases where there is no conceptual max on

>>>a value (last name, for example), a max length is chosen for the
>>>attribute definition to the dbms.
>>
>>"is chosen" by whom? Who made the choice?
>
> The application software designers in line with their users (not those
> who wrote the dbms toolset, if that is the question)

Yep, that was the question.

I only don't like the "in line with their users" part
- how can they be in line with their users and introduce
constraints which are not in the conceptual model?
It sounds as if they made it up themselves.
Maybe for bad reasons, maybe for good reasons,
but, in the context of this question (max length
in the database, but not in the conceptual model)
/not/ "in line with their users".

[snip]

>>>>>I do want the software product (as a whole) to limit
>>>>>anything which has a conceptual limit.
>>>>
>>>>This is a reason to put the conceptual limits as
>>>>close to the data as possible. If they are enforced in
>>>>the database the rest of the software product
>>>>has to follow suit. Any other way isn't
>>>>garantueed, is it?
>>>
>>>Nothin' is guaranteed, mAsterdam, I undertsand your point.
>>
>>Your "there should be no data entry widget that permits entry of
>>more than 2 characters for a state code" tells me you have not
>>digested that understanding.
>
> No, it tells you that I have not adopted it as my own opinion.
> I understand, and do not write-off, your point.
> It still isn't mine, however.

I am not convinced you do.
However we may reserve this topic for another thread :-)

How so?

>>They (the designers of the dbms) have the responsability to
>>provide facilities for the db designers to specify them,
>>and the facilities to enforce the specified constraints.
>
> And the option to provide a feature permitting app or db designers not
> to specify a size., the option to default to variable length unless
> otherwise specified, for example.

And suddenly it's about providing clever defaults!

[J M Davitt]

Thanks for the correction.

I'm done.

>
> magoo

[David Cressey]

"mAsterdam" <mAst...@vrijdag.org> wrote in message
news:4479af0b$0$31647$e4fe...@news.xs4all.nl...

Dawn has previously admitted to "pushing people's buttons". What she hasn't
admitted to is making statements she knows to be false just to push people's
buttons.

However, she claims to be a well seasoned programmer on all kinds of
systems ranging from IMS to Oracle, a technical leader, a manager, and a
college professor. Yet she claims to be ignorant of things that any of the
rest of us would expect EVERY such person to know.

We're never going to be able to check out her knowledge base. Not even if
she were imprisoned in Guantanamo Bay with Bob Badour as a guard.

So we're just going to have to take if for granted that she is who she says
she is, and doesn't know what she claims not to know.

The beauty of having these conversations is that you can have the same
conversaion a couple of years later, try another tack, and see where that
leads. It reminds me of "Groundhog Day".

[dawn]

mAsterdam wrote:
> dawn wrote:
> > mAsterdam wrote:
> >>dawn wrote:
> >>>mAsterdam wrote:
> >>>>dawn wrote:
> >>>>>Marshall wrote:
> >>>>>>dawn wrote:
> >>>>>>
> >>>>>>>[why all the length constraints?]
>
> >>>... even in cases where there is no conceptual max on
> >>>a value (last name, for example), a max length is chosen for the
> >>>attribute definition to the dbms.
> >>
> >>"is chosen" by whom? Who made the choice?
> >
> > The application software designers in line with their users (not those
> > who wrote the dbms toolset, if that is the question)
>
> Yep, that was the question.
>
> I only don't like the "in line with their users" part
> - how can they be in line with their users and introduce
> constraints which are not in the conceptual model?

Yes, that is a problem. However, I like to keep the conceptual model
as pure from implementation (e.g. choice of database product) as
feasible, so you would not want to introduce unnecessary (from a
business perspective) constraints there. It was when examining the
"mapping" (perhaps too strong a word, possibly lacking the suggestion
that there is creativity in the design when there is) from conceptual
to implementation (aka logical data model) with a fine tooth comb that
I noticed this introduction.

But I do think that design and not just conceptual model need to be "in
line with their users" too. You simply have to go back to them beyond
the conceptual model and include them in the
design-as-the-computer-needs-it while doing design for a specific
implementation of the model. In theory (although rarely in practice)
the choice of target DBMS need not be made prior to the conceptual
model being complete, right?

> It sounds as if they made it up themselves.
> Maybe for bad reasons, maybe for good reasons,
> but, in the context of this question (max length
> in the database, but not in the conceptual model)
> /not/ "in line with their users".
>
> [snip]
>
> >>>>>I do want the software product (as a whole) to limit
> >>>>>anything which has a conceptual limit.
> >>>>
> >>>>This is a reason to put the conceptual limits as
> >>>>close to the data as possible. If they are enforced in
> >>>>the database the rest of the software product
> >>>>has to follow suit. Any other way isn't
> >>>>garantueed, is it?
> >>>
> >>>Nothin' is guaranteed, mAsterdam, I undertsand your point.
> >>
> >>Your "there should be no data entry widget that permits entry of
> >>more than 2 characters for a state code" tells me you have not
> >>digested that understanding.
> >
> > No, it tells you that I have not adopted it as my own opinion.
> > I understand, and do not write-off, your point.
> > It still isn't mine, however.
>
> I am not convinced you do.
> However we may reserve this topic for another thread :-)

Fair enough.

By their design of the DBMS. If it is designed such that specifying
attribute max length constraints gives some benefit to their users (aka
software developers) or that their users must specify such constraints,
that would be different than if they came up with a design where there
was no benefit to having developers specify such. (Was that clear or
not?)

> >>They (the designers of the dbms) have the responsability to
> >>provide facilities for the db designers to specify them,
> >>and the facilities to enforce the specified constraints.
> >
> > And the option to provide a feature permitting app or db designers not
> > to specify a size., the option to default to variable length unless
> > otherwise specified, for example.
>
> And suddenly it's about providing clever defaults!

I somehow don't think that is what a Pick DBMS does. So, I don't think
that is what it is about. As always, I could be missing something.
Thanks. --dawn

[dawn]

Note: there is no answer to the OP question nor even advancing of it
below, just banter out of frustration, for what it's worth.

David Cressey wrote:
> "mAsterdam" <mAst...@vrijdag.org> wrote in message
> news:4479af0b$0$31647$e4fe...@news.xs4all.nl...
> > dawn wrote:
> > > Keith H Duggar wrote:
> > >
> > >>dawn wrote:
> > >>
> > >>>... Why give a max length to
> > >>>an attribute that doesn't conceptually require such? Why
> > >>>can't the DBMS handle that for you (efficiently, of
> > >>>course)?
> > >>
> > >>Who says they cannot? Do you realize that even if no DBMS
> > >>implementation has yet done so, this is not evidence of
> > >>impossibility.
> >
> > > That would be the reason for my question. I am asking what is the
> > > reason that all of the implementations of the RM work with a max length
> > > constraint on attributes. So I should have written "why couldn't the
> > > DBMS...", perhaps, but most would understand the rhetorical technique,
> > > I would think.
> >
> > Even better:
> > "Why don't the DB designers let the DBMS handle it."
> > (Summary of my answer your OP: Because they trust
> > specifying it from earlier solutions.)
> >
> > As soon as you say "can't" in relation to a pet tool or model
> > you are waving a red cloth in front of a bull.

Yes, and I should have said "couldn't" instead of "can't". I will try
to be more cautious.

> > Not unlike Neo's unfounded "prolog can't do this" or
> > "RM can't do that" statements repeated ad nauseam.
> >
> > This gives room to responses like:
> >
> > >>This is a classic example of argument from
> > >>ignorance or the burden of proof logical fallacy.
> > >
> > >
> > > You seem to think I'm arguing something when I think I am asking
> > > something.
> >
> > You shouldn't have waved the red towel :-)

If it had been a verbal face-to-face discussion, my choice of terms
would not have been a problem. I write with a speaking style but will
try to be more aware of where someone might jump to such an incorrect
conclusion if they are thinking the worst of me.

> > >>And yet
> > >>you imply this fallacious claim from the start of the
> > >>thread. Do you understand this is a logical fallacy?
> >
> > [snip etc. etc.]
> >
> > > I have no answer I'm driving at, but am trying to understand. I have
> > > worked from the user to the app-implementation of many varied "data
> > > processing" systems, but have never written a DBMS tool. 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.
> >
> > Here you are suggesting again they aren't part of
> > the database design but part of the dbms.
> > They are not - another red towel. You could easily make
> > your statement in a way which shows you understand
> > that difference.
> >
> > [snip]
> >
> > > 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.
> >
> > The db designer determines attribute length constraints, not the dbms.
> > Why do you ignore this difference?
> >
> > [snip]
>
> Dawn has previously admitted to "pushing people's buttons". What she hasn't
> admitted to is making statements she knows to be false just to push people's
> buttons.

Yes, I try to put smilies or other clues in so people know if I'm aware
of joking or pushing buttons on purpose. One friend told me years ago
that I had a U of M(ichigan) sense of humor (and I was around U of M
until the age of 6 so maybe that's true).

However, I do not knowingly state things that I don't agree with. I'm
not playing devil's advocate. I have a perspective which I know comes
more from the "programmer" than "dba" perspective. While I doubt I
state many opinions where I'm the only IT professional holding such an
opinion, I might sometimes be the only one stating it on cdt. I know
I'm not all-knowing nor 100% accurate, and I learn a lot and have
refined my own thinking considerably from hearing the perspective of
you and others. I have not changed every opinion I have, however,
perhaps because they are not all wrong ;-)

> However, she claims to be a well seasoned programmer on all kinds of
> systems ranging from IMS to Oracle,

Seasoned (I prefer that term to "mature"), yes, but I try not to make
claims, just provide anecdotes where I think relevant. I have seen
successes and failures and have had enough experiences to form some
opinions, again, some of which might be incorrect and skewed by my
experiences, so I like knowing what others think too. This would be
the case for anyone, I would think.

> a technical leader, a manager, and a
> college professor.

You missed "mom" and a few other important roles I'll skip. While I
will claim to have done plenty of coding with IMS (quite some years
ago), I have done only a little programming with Oracle, MySQL, and
PostgreSQL, and none of that very recently, having more experience in
mgmt with SQL-DBMS's as well as Pick. I don't have a Ph.D. and have
only taught during 5 years of my career to date, while spending more
than 25 as a practitioner in one role or another. These are simply
facts. It bothers me when you or anyone says I'm claiming something
since it is very unlike me to try to flex any muscle or even want to do
such. The primary thing I've claimed is ignorance, which means that my
detractors and I agree on at least that.

> Yet she claims to be ignorant of things that any of the
> rest of us would expect EVERY such person to know.

If people want to tell me how ignorant I am, I don't mind agreeing. I
have anecdotal, but not scientific, evidence that men are less inclined
to admit ignorance or even to show it with their questions. If you
would prefer that I tell you that I know a lot more than some people
around here give me credit for, then I can do that, but I've never met
a person who was not ignorant and I'm no exception.

Do you have an example of something that I have said I do not know that
EVERY person who has been in the software development profession for a
quarter of a century does know or should know? I don't doubt I've
missed something, but I suspect everyone has.

> We're never going to be able to check out her knowledge base.

Since I'm writing here to learn and not teach, I guess that would be
difficult since I ask questions for which I don't know the answer.
However, I suspect there are a few clues, whether here or in my blog,
that might lead you to believe that I'm not completely ignorant in the
area of s/w development, right?

[BTW. I'm headed to the Seattle area (where I have never been before)
and speaking at a little gathering there on the 15th. If anyone is out
that way and wants to chat with me in person (some exceptions may
apply) or hear me speak (2 talks, one on AJAX and the other on data
modeling, to a Pick audience), let me know (I think they charge a small
fee for the meeting to cover expenses).]

> Not even if
> she were imprisoned in Guantanamo Bay with Bob Badour as a guard.

Laughing.

> So we're just going to have to take if for granted that she is who she says
> she is, and doesn't know what she claims not to know.

More laughter. I was unaware of claiming anything outside of telling
stories, and I don't mean to be claiming I'm anything or anyone,
brother David, just a human being with questions and opinions.

> The beauty of having these conversations is that you can have the same
> conversaion a couple of years later, try another tack, and see where that
> leads. It reminds me of "Groundhog Day".

Me too. Maybe I'm forgetting things, but I think I'm asking different
questions or at least seeking the answer to a different question each
time. Someone once pointed out in cdt that I was repeating a question
a year later. I can only claim middle age, hormones, or whatever
reason for such a brain failure. My memory is sometimes fuzzy, perhaps
the first stages of alzheimers (no, I shouldn't joke about that, my
mother-in-law died of it). Do you know women over 45 who do not have
such memory lapses? Tips are welcome, but I do my best.

If this particular question (max length constraints) has been asked and
answered before, my apologies, but then it should be really easy to
provide a logically convincing answer the second time around. I don't
completely know the answer now (in spite of all of the responses), so
maybe I'm not just ignorant but brain dead. Thanks for putting up with
me in spite of that, David. Cheers! --dawn

[Keith H Duggar]

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

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

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

[mAsterdam]

dawn wrote:
> mAsterdam wrote:
>>dawn wrote:
>>>mAsterdam wrote:
>>>>dawn wrote:
>>>>>mAsterdam wrote:
>>>>>>dawn wrote:
>>>>>>>Marshall wrote:
>>>>>>>>dawn wrote:
>>>>>>>>
>>>>>>>>>[why all the length constraints?]
>>
>>>>>... even in cases where there is no conceptual max on
>>>>>a value (last name, for example), a max length is chosen for the
>>>>>attribute definition to the dbms.
>>>>
>>>>"is chosen" by whom? Who made the choice?
>>>
>>>The application software designers in line with their users (not those
>>>who wrote the dbms toolset, if that is the question)
>>
>>Yep, that was the question.
>>
>>I only don't like the "in line with their users" part
>>- how can they be in line with their users and introduce
>>constraints which are not in the conceptual model?
>
> Yes, that is a problem.

Not really.

The constraints chosen by
"the application software designers in line with their users"
are part of the conceptual model.
A "max length .. for the attribute definition to the dbms.",

"even in cases where there is no conceptual max on a value
(last name, for example)",

OTOH, is not.
The remark "in line with their users" simply
contradicts your previously stated assumption
"there is no conceptual max".

> However, I like to keep the conceptual model
> as pure from implementation (e.g. choice of database product)

[Topic switch alert]

Every product, capable of enforcing the constraints
from the conceptual model will do. In practise this means
that unenforcable constraints are scratched from the
requirements.
Back on topic: Often the conceptual model will not
be a deliverable or even explicit but re-engineered
from the implementation when it matters.
These databases can not be qualified as designed

"in line with their users".

> as

> feasible, so you would not want to introduce unnecessary (from a
> business perspective) constraints there. It was when examining the
> "mapping" (perhaps too strong a word, possibly lacking the suggestion
> that there is creativity in the design when there is) from conceptual
> to implementation (aka logical data model) with a fine tooth comb that
> I noticed this introduction.
> But I do think that design and not just conceptual model need to be "in
> line with their users" too.

Yep. You should really read up on ORM: http://www.orm.net/

> You simply have to go back to them beyond
> the conceptual model and include them in the
> design-as-the-computer-needs-it while doing design for a specific
> implementation of the model. In theory (although rarely in practice)
> the choice of target DBMS need not be made prior to the conceptual
> model being complete, right?

Last time I have seen that (some level of completeness)
from close-by is long ago. Apart from the dropped
availability threshold (since when can we download
a full-fledged dbms just to try it?) there is also
something called Analysis-paralysis
http://en.wikipedia.org/wiki/Analysis_paralysis
and the IKIWISI syndrome.
http://www.nuigalway.ie/bis/mlang/lecture_notes/systems_development/Rapid_and_Agile_Approaches.ppt

The timing of these decisions need to be carefully balanced:
http://agiledevelopmentconference.com/2003/files/P4Paper.pdf

>>It sounds as if they made it up themselves.
>>Maybe for bad reasons, maybe for good reasons,
>>but, in the context of this question (max length
>>in the database, but not in the conceptual model)
>>/not/ "in line with their users".

[snip]

>>>... the database designers select max lengths, and

>>>the dbms designers choose whether and how big a
>>>penalty would be if size were not declared.
>>
>>How so?
>
> By their design of the DBMS. If it is designed such that specifying
> attribute max length constraints gives some benefit to their users (aka
> software developers) or that their users must specify such constraints,
> that would be different than if they came up with a design where there
> was no benefit to having developers specify such. (Was that clear or
> not?)

Hmm... it is as if these nasty DBMS designers play a giant trick
by awarding benefits to those who specify max length constraints.
I don't buy it.

>>>>They (the designers of the dbms) have the responsability to
>>>>provide facilities for the db designers to specify them,
>>>>and the facilities to enforce the specified constraints.
>>>
>>>And the option to provide a feature permitting app or db designers not
>>>to specify a size., the option to default to variable length unless
>>>otherwise specified, for example.
>>
>>And suddenly it's about providing clever defaults!
>
>
> I somehow don't think that is what a Pick DBMS does. So, I don't think
> that is what it is about. As always, I could be missing something.

Well, to me it looks like your views on problems are heavily
biased by the solutions you are most comfortable with.
You are not alone.

[Alvin Ryder]

dawn wrote:
>
> Is there something about the RM that would prompt all (or most?)
> existing implementations (however flawed) to drive developers to add in
> these constraints for performance, space saving, or other reasons? I
> realize there can be variable length attributes, but specifying a max
> field length still seems to be the norm (is that still the case?)
>

Hi dawn,

There is nothing in the RM that prompts these constraints, it mandates
only the existence of the boolean type, all other types are user (dbms)
definable.

The constraints are related to performance, disk space management,
developer time, the languages used and computing in general.

> As many of you know, I work with database management systems that treat
> all data as variable in length, while one might specify a length for
> display purposes.
>

Are you sure all the data is variable? Or is it limited to something
large like 2^32 (4Gb) which *appears* to be unlimited but in fact
isn't? Can attributes exceed the resident RAM size? Can they exceed the
disk size? I seriously doubt it.

At any rate most RDBMs have CLOB types which provide something similar.
CLOB's aren't used as frequently as VARCHARs because they are much less
efficient. Again that has nothing to do with the RM but with computing
in general.

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

Outputs and fonts are not database concerns at all so that isn't the
reason.

Imagine a 32 bit integer versus an arbitrary precision number which has
any number of bits! The former only requires 32 bits but the latter
needs a way to represent the size and then you must represent the
variable length data itself. Which is easier? Which is faster?

The fixed length data might waste some bits but up to it's limit
everything is cut, dry and efficient. The variable length data is more
complex, slower and it isn't infinite after all.

The same holds true or strings. And in turn the same holds for records
made up of such attributes. Furthermore once you store records on disk
what happens when they outgrow their current location?

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

Yes you can write any system with variable length data but *no* you
cannot do it without cost. All of this has nothing to do with the RM,
we could be talking about word processors, databases or games. You just
can't have your cake and eat it too.

> TIA. --dawn

Cheers.

[mAsterdam]

dawn wrote:
> Note: there is no answer to the OP question nor even advancing of it
> below, just banter out of frustration, for what it's worth.
>
>David Cressey wrote:

>>mAsterdam wrote:

>>>As soon as you say "can't" in relation to a pet tool or model
>>>you are waving a red cloth in front of a bull.
>
> Yes, and I should have said "couldn't" instead of "can't". I will try
> to be more cautious.

Do you really think the bull notices the difference?
I don't.

>>>Not unlike Neo's unfounded "prolog can't do this" or
>>>"RM can't do that" statements repeated ad nauseam.
>>>
>>>This gives room to responses like:

[Keith H Duggar:]

>>>>>This is a classic example of argument from
>>>>>ignorance or the burden of proof logical fallacy.
>>>>

[dawn:]

>>>>You seem to think I'm arguing something when I think I am asking
>>>>something.
>>>
>>>You shouldn't have waved the red towel :-)
>
> If it had been a verbal face-to-face discussion, my choice of terms
> would not have been a problem.

Yes, and there would be other social mechanisms in place.
This forum isn't face-to-face though.

> I write with a speaking style but will
> try to be more aware of where someone might jump to such an incorrect
> conclusion if they are thinking the worst of me.

[snip]

>>>Here you are suggesting again they aren't part of
>>>the database design but part of the dbms.
>>>They are not - another red towel. You could easily make
>>>your statement in a way which shows you understand
>>>that difference.

[snip]

>>>>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.
>>>
>>>The db designer determines attribute length constraints, not the dbms.
>>>Why do you ignore this difference?
>>>
>>>[snip]
>>
>>Dawn has previously admitted to "pushing people's buttons". What she hasn't
>>admitted to is making statements she knows to be false just to push people's
>>buttons.
>
>
> Yes, I try to put smilies or other clues in so people know if I'm aware
> of joking or pushing buttons on purpose. One friend told me years ago
> that I had a U of M(ichigan) sense of humor (and I was around U of M
> until the age of 6 so maybe that's true).
>
> However, I do not knowingly state things that I don't agree with. I'm
> not playing devil's advocate. I have a perspective which I know comes
> more from the "programmer" than "dba" perspective. While I doubt I
> state many opinions where I'm the only IT professional holding such an
> opinion, I might sometimes be the only one stating it on cdt.

I'ld welcome those professionals - I would like to see
some other perspectives. Anybody seriously considering
to contribute from outside the RM will start reading
some recent posts and suspect that they will not be
treated politely, though. Not very attractive.

Ah RM is Real Men!

Kidding aside, it depends on the company.

It takes more stamina to show ignorance in this newsgroup
now, than it did say a year ago.
I have recently refrained from asking questions
revealing ignorance because of anticipated reactions
here - even when it would just be about exact wording.

My favourite writer in dutch literature had "nescio" as pseudonym.

[paul c]

dawn wrote:
> paul c wrote:
>
>>J M Davitt wrote:
>>
>>>dawn wrote:
>>>
>>>
>>>>J M Davitt wrote:
>>>>
>>>>
>>>>>dawn wrote:
>>>>>
>>>>>
>>>>>>...
>>
>>This is a plea to stop this silly thread.
>
>
> Honest questions might seem silly until you understand. The purpose of
> asking questions is to understand better. If you think it silly, then
> you need not answer.

> ...

it's pretty clear based on the attention this stuff gets that people who
are interested in seeing real progress in this field and who let the
really irrelevant questions ride are doing a disservice to those who
have an honest interest in it.

>
>>Also to humbly point out to
>>those born after the fact that VSAM has as much to do with the various
>>RM's as Christianity does (that OCCURS stuff was in Cobol, not VSAM, in
>>fact VSAM had no notion of fields, just bytes and offsets).
>
>
> I was going to point that out but thought it was nitpicking to do so.
> I simply redirected his point to COBOL instead. Perhaps it was not
> necessary to specify lengths when working with VSAM, but I only saw it

> done that way. ...

well, if you can't remember what you saw, i doubt if anybody else could
guess. i could have been a little more accurate about VSAM, not that
that would not be likely to do much good in this case. one could
specify a record length in bytes which was not always strictly an offset
since variable length recs were allowed, in which case the "length" was
a maximum length, either 32k-1 or 64k-1, i forget. plus a length in
bytes for a "key", regardless of how many fields were externally imputed
to that key. regardless, i fail to see what Cobol has got to do with
the RM. a comparison with assembler or even C might be apt as enough
experience with those might lead one to conclude that data lengths for
physical purposes could be suppressed in a UI except for when there was
some logical reason for a limit. VSAM had just come out when Codd wrote
his first paper but it wasn't really new, just an amalgam of previous
access methods and it was also the new underpinning for IMS so i'd bet
that Codd had its extremely limited physical perspective in mind when he
wrote his stuff.

m

[Bob Badour]

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.

Theory for domain support is not off-topic. Theory that supports
implementation is not off-topic. Computational complexity theory is not
off-topic. Reiterating alternate allocators and iterators for the
standard template library would be off-topic. In that case, the
appropriate response is UTSL.

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

[Tony D]

(I'll take these points intentionally out of sequence, in order of
interest/worth/whatever.)

Dawn wrote :

> I read 'em, but didn't memorize 'em, feel free to point me to a page
> number that answers my question.

If you aren't internalising anything you've read from them, including
the basic point upon which one of them rests, why bother reading them ?

> Maybe it is a reasonable question to ask

Not really.

> and maybe there is a good reasonable response.

I could be mildly provocative and suggest the Principle of Incoherence
may apply here.

> Maybe you know the good reasonable response and
> have decided not to offer it and trash me instead,

At time of this writing, my version of something approaching a
reasonable response is at post number 49 on the Google list. Maybe you
didn't read that far down ?

> or maybe you don't know the response either in which case we could both learn
> something from the thread.

Hm.

> This is SOOOOO frustrating I could scream!

Well then, we have at least one thing in common. As to why, I shall now
jump backwards and a little out of sequence :

> Thankfully some like David, Marshall, JOG, x, mAsterdam, Jan and many
> others do try to discuss the topics, but I'm sure they are tiring of
> having so much noise in these discussions too.

Indeed they do. Jan, Mikito, Bob and increasingly Marshall are offering
useful information, interesting, meaty topics for discussion and points
of insight. Sadly, it's sometimes quite hard work to find the nuggets,
but they are there.

> Why not answer questions, participate in the discussion,

When I feel I have something useful to say, even if it is only to urge
caution and point to more learned sources then I try to. If my lattice
chops were up to snuff I'd like to participate in the relational
lattice discussions, for example. But they aren't, so I don't, and
simply read instead.

> or ignore the thread instead of this approach?

Generally, ignoring this type of thread is a very worthwhile approach,
and one I would recommend heartily. This one, however, was so
impressively dopey, given the widely available material on the topic,
that I couldn't resist. I will count that as my bad.

> What is your purpose for particiipating in this thread only to try to make this a discussion about me
> instead of the question I asked?

Someone else seemed to be coming to the same conclusion I came to some
time ago, and I noted it. As for making things a discussion about you,
the evidence would suggest you manage that quite successfully for
yourself.

>> This particular thread is so close to being a troll,
> hogwash

Actually, it's darn close to being a troll, because (a) source material
is readily available to answer the question; (b) you claim to have read
at least one book which would have answered your question already, and
(c) the question was asked in such a way that there are several on the
list who were bound to answer in a sadly predictable way (surely after
all this time we're past conflating SQL with the relational model of
data ?). It was the c.d.t. equivalent of waving a red rag at a bull, as
another poster noted elsewhere.

- Tony

[Keith H Duggar]

mAsterdam wrote:

> dawn wrote:
> > If people want to tell me how ignorant I am, I don't
> > mind agreeing.

Are you honestly sure about that?

> > I have anecdotal, but not scientific, evidence that men
> > are less inclined to admit ignorance or even to show it
> > with their questions.

Even if that generalization were true (I'm a man and
/readily/ admit ignorance and accept superior reasoning when
it is demonstrated), how is it relevant to this discussion?
Why do you keep bringing up irrelevant facts such as your
gender, the house your daughter owns, the awards the other
received, etc? Do you /want/ us to pigeonhole you as an
irrational emotional hormonal woman?

> > Do you have an example of something that I have said I
> > do not know that EVERY person who has been in the
> > software development profession for a
> > quarter of a century does know or should know?

Yes, this comes to mind:

> > 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 think any computer science curriculum would
teach this. And thus isn't this something EVERY software
development professional should know? And if you did miss
this fundamental concept, no problem. Just admit it. Live up
to your "I don't mind agreeing" claim. So you missed a core
concept, no problem, it happens. It's good that you can pick
it up here and now. Admit and accept your ignorance so you
learn and move on. It is cathartic, it feels good, try it.

> It takes more stamina to show ignorance in this newsgroup
> now, than it did say a year ago. I have recently refrained
> from asking questions revealing ignorance because of
> anticipated reactions here - even when it would just be
> about exact wording.

Strange, not my experience here at all. I dropped by a few
weeks ago, readily admitted I was ignorant, participated a
little, asked some questions, and was treated VERY
well. When asking database related questions I tried to do
so with humility and was not vociferous. Could this have
been a factor in my treatment?

Perhaps your hesitancy has more to do with personal pride?
If so you could create an alternate google account (I would
go for "y" to match up with "x") and post questions using
that account. Perhaps you will discover good treatment and
relax enough to post questions from you main account.

-- Keith --

[paul c]

mAsterdam wrote:
> ...

>
> I'ld welcome those professionals - I would like to see
> some other perspectives. Anybody seriously considering
> to contribute from outside the RM will start reading
> some recent posts and suspect that they will not be
> treated politely, though. Not very attractive.

> ...

The thing is, saying "i've got this system that goes 'up' when i press
this button and goes 'down' when i press that button" isn't nearly
enough to qualify for discussion, no matter who the "professional" is.
What was remarkable for me about the rm was that it found very
precise parallels (maybe analogues is a better word, but metaphor is too
sloppy a word) that allowed one to make a machine interpretation of an
established mental system, both predictable as far as Turing, Godel et
cetera allow. I think the people who propose alternatives need to
establish the same connection before they start throwing new operators
and metaphors around. There remain, IMO, basic issues to do with the rm
that haven't been completely sorted out, for example the proper place
for rva's (eg. implementation versus interface, predicates about sets
versus predicates about single logical variables) but these don't change
the value of the original insight.

m

[Bob Badour]

Keith H Duggar wrote:

Keith, don't encourage her!!! She pollutes the newsgroup enough with one
email address!

[Keith H Duggar]

Bob Badour wrote:
> Keith H Duggar wrote:
> > mAsterdam wrote:
> > > I have recently refrained from asking questions
> > > revealing ignorance because of anticipated reactions

> > > here ...

> >
> > If so you could create an alternate google account (I
> > would go for "y" to match up with "x") and post
> > questions using that account. Perhaps you will discover
> > good treatment and relax enough to post questions from
> > you main account.
>
> Keith, don't encourage her!!! She pollutes the newsgroup
> enough with one email address!

Hehe, sorry. I was actually suggesting that to mAsterdam. I
don't think DW hesitates to post. Especially considering she
is the 3rd most frequent poster this month and the 6th most
frequent of all time and she has only been posting for about
4 years out of the 14 the group is archived.

> Theory for domain support is not off-topic. Theory that
> supports implementation is not off-topic. Computational
> complexity theory is not off-topic. Reiterating alternate
> allocators and iterators for the standard template
> library would be off-topic. In that case, the appropriate
> response is UTSL.

Ok understood, makes sense considering the .theory. And in
that case what I had in mind is definitely off-topic.

Thanks.

-- Keith --

[dawn]

Keith H Duggar wrote:
> mAsterdam wrote:
> > dawn wrote:
> > > If people want to tell me how ignorant I am, I don't
> > > mind agreeing.
>
> Are you honestly sure about that?

Yes.
<snip>

> > > Do you have an example of something that I have said I
> > > do not know that EVERY person who has been in the
> > > software development profession for a
> > > quarter of a century does know or should know?
>
> Yes, this comes to mind:

OK, so you have a clear reasoned answer to my question then?

> > > 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? 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? Does it depend on the implementation of the DBMS as to
whether those particular constraint specifications provide much, if
any, assist to the performance?

> And if you did miss
> this fundamental concept,

Then I missed it in my own reading or on the job, which is where almost
all of my CS education has been, which means that it was not in an area
I cared about before but do now.

> no problem. Just admit it.

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. I think I have even seen a counter-example.

> Live up
> to your "I don't mind agreeing" claim. So you missed a core
> concept, no problem, it happens. It's good that you can pick
> it up here and now. Admit and accept your ignorance so you
> learn and move on. It is cathartic, it feels good, try it.

I'm ignorant. I asked a question, knowing it was a question from
ignorance. I have not yet felt enlighted, however. I am sorry to be
so dense, but could 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?

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?

> > It takes more stamina to show ignorance in this newsgroup
> > now, than it did say a year ago. I have recently refrained
> > from asking questions revealing ignorance because of
> > anticipated reactions here - even when it would just be
> > about exact wording.
>
> Strange, not my experience here at all. I dropped by a few
> weeks ago, readily admitted I was ignorant, participated a
> little, asked some questions, and was treated VERY
> well. When asking database related questions I tried to do
> so with humility and was not vociferous. Could this have
> been a factor in my treatment?
>
> Perhaps your hesitancy has more to do with personal pride?

I no not what I'm hesitant about nor what I'm prideful about. If I
have needed to be humbled, I certainly have been. In all my life I
have never heard such horrible things about myself as I have from this
newsgroup. Based on that I have done more reflection than ever before
in my life as well. But I decided to keep going with my studies and
continue using this forum to ask questions as I have them. There are
plenty of helpful people here, but right now there are far too many who
insist on not addressing my questions, but me. That is the reason that
I have said things about myself more recently. I thought that might
help address concerns (such as some thinking I'm not actually asking
honest questions when I am).

> If so you could create an alternate google account (I would
> go for "y" to match up with "x") and post questions using
> that account.

A reason not to do that is that those who are not interested in my
topics or discussions on this (I'm not enjoying this discussion
myself!) are filtering me out. It doesn't seem fair to then pop up
elsewhere. If you don't like my questions, my angle, my opinions, or
my personality, you need not engage.

> Perhaps you will discover good treatment and
> relax enough to post questions from you main account.

I receive good treatment from many of those here, but terrible
treatment from some. I have tried hard to learn the proper vocabulary,
but still seem to miss the mark. I now suspect there is little or
nothing that I really could do to satisfy those who are not interested
in these topics that are typically about, rather than within, database
theory other than to take my questions elsewhere.

I suspect I will refrain from posting another new question or topic for
quite some time, but that doesn't stop me from wanting to know the full
answer to this one. If it is buried within this thread, I have not yet
found and understood it. --dawn

[paul c]

paul c wrote:
> ... VSAM had just come out when Codd wrote

> his first paper but it wasn't really new, just an amalgam of previous
> access methods and it was also the new underpinning for IMS so i'd bet
> that Codd had its extremely limited physical perspective in mind when he
> wrote his stuff.

plus he may have been p-offed because the OS buggers/pretend technocrats
had misconceived the purposes of db support yet again and even though so
long ago, not for the last time (not that i admire the polico
technocrats). there's much i don't understand, still why do i not have
the patience to read many of these topics except when i'm heavily into
the plonk? figuring out why, though pointless, has got to be as
significant as many of the posts here. sorry about the uncustomary
nuance and please don't answer. please, please don't.

p

[dawn]

Tony D wrote:
> (I'll take these points intentionally out of sequence, in order of
> interest/worth/whatever.)
>
> Dawn wrote :
>
> > I read 'em, but didn't memorize 'em, feel free to point me to a page
> > number that answers my question.
>
> If you aren't internalising anything you've read from them, including
> the basic point upon which one of them rests, why bother reading them ?

I'm very, very intersted in them or I wouldn't shell out either the
dollars or the time. A first read at any book does not have me
memorizing it, however, and I usually have a lot of questions from
anything I read. I still don't know where in the book the answer to my
question is (I've looked, but there is no way to google within it ;-)
so if you have a page number for me, please pass it along.

> > Maybe it is a reasonable question to ask
>
> Not really.

Could you be more specific on what is not reasonable about the
question?

> > and maybe there is a good reasonable response.
>
> I could be mildly provocative and suggest the Principle of Incoherence
> may apply here.

You may suggest that, but it isn't helpful in addressing the question.

> > Maybe you know the good reasonable response and
> > have decided not to offer it and trash me instead,
>
> At time of this writing, my version of something approaching a
> reasonable response is at post number 49 on the Google list. Maybe you
> didn't read that far down ?

I will look for it. Thanks.

> > or maybe you don't know the response either in which case we could both learn
> > something from the thread.
>
> Hm.
>
> > This is SOOOOO frustrating I could scream!
>
> Well then, we have at least one thing in common. As to why, I shall now
> jump backwards and a little out of sequence :
>
> > Thankfully some like David, Marshall, JOG, x, mAsterdam, Jan and many
> > others do try to discuss the topics, but I'm sure they are tiring of
> > having so much noise in these discussions too.
>
> Indeed they do. Jan, Mikito, Bob and increasingly Marshall are offering
> useful information, interesting, meaty topics for discussion and points
> of insight. Sadly, it's sometimes quite hard work to find the nuggets,
> but they are there.
>
> > Why not answer questions, participate in the discussion,
>
> When I feel I have something useful to say, even if it is only to urge
> caution and point to more learned sources then I try to. If my lattice
> chops were up to snuff I'd like to participate in the relational
> lattice discussions, for example. But they aren't, so I don't, and
> simply read instead.

ditto.

> > or ignore the thread instead of this approach?
>
> Generally, ignoring this type of thread is a very worthwhile approach,
> and one I would recommend heartily. This one, however, was so
> impressively dopey, given the widely available material on the topic,
> that I couldn't resist. I will count that as my bad.

Feel free to point me to this widely available material that answers my
question.

> > What is your purpose for particiipating in this thread only to try to make this a discussion about me
> > instead of the question I asked?
>
> Someone else seemed to be coming to the same conclusion I came to some
> time ago, and I noted it. As for making things a discussion about you,
> the evidence would suggest you manage that quite successfully for
> yourself.

As I just mentioned in another thread, when the discussion was turned
on me, instead of ignoring it I have been trying to explain and will
try to stop doing that once I have an understanding of the answer to my
question here.

> >> This particular thread is so close to being a troll,
> > hogwash
>
> Actually, it's darn close to being a troll, because (a) source material
> is readily available to answer the question;

One would think someone could just point me to something and be done
with it then.

> (b) you claim to have read
> at least one book which would have answered your question already, and

I didn't get that from it, so I will comtinue to look.

> (c) the question was asked in such a way that there are several on the
> list who were bound to answer in a sadly predictable way (surely after
> all this time we're past conflating SQL with the relational model of
> data ?).

I would think so too -- the RM is a theory related to databases and SQL
and SQL-DBMS's are implementations which are flawed even if based on or
prompted by the work done on relational theory. Is that accurate?

I'm interested in practice as it relates to theory. Sometime features
are in SQL-DBMS products because of old theory. 3VL might be an
example of that. The state of the RM today might not care whether it
is implemented with 2 or 3VL, but that does not mean that historically
the RM had nothign to do with the state of the industry today being
that many use a 3VL.

> It was the c.d.t. equivalent of waving a red rag at a bull, as
> another poster noted elsewhere.
>

Sometimes I'm aware when I do that, but this time I definitely was not.
I even put a note up front that I hoped would keep those who insist on
seeing red rags from commenting. Ugh! --dawn

[dawn]

Tony D wrote:
> Yes, it is a rather silly question. It's an almost impressively silly
> question because if, as you've mentioned elsewhere, you've read TTM,
> you should have seen stated in several different ways the assertion
> that the relational model is orthogonal to the type system. A quick
> Google found an interview (http://www.dbmsmag.com/int9410.html)
> discussing an earlier version of the book, where Date says :
>
> "The reason I say the ideas of object-oriented (at least the good ones)
> are orthogonal to the ideas of the relational model is that *nowhere
> does the relational model prescribe what data types you have*."

That I know. That does not answer my question. I fully understand
that one need not specify max length constraints if implementing only
"in theory." I wondered if there were anything in the theory that
might prompt implementations that have, perhaps as a side-effect, the
need for or advantage when individual attributes are specified with max
length constraints. That is not at all the same question as whether
such the theory says that the implementations must have such a feature.

> Unless the subtext was to have another tussle over the old "what's a
> scalar type ?" question ...

By no means.

> If you're asking "why do (at least the majority) of SQL databases
> require length constraints", then it's very probably to do with the way
> those products chose to represent tables on disk.

Yes.

> There may also be
> "bleed" from other language designs into SQL

Yes. mAsterdam's serif analogy might be applied to the physical
implementations as well as the feature sets.

It hesitate to report that I still don't know the answer to my
question, but I will research it differently and see if I can get
further. It actually thought it would have a simple answer and that
someone would have that answer handy enough to pass it along, but it
seems you and others misinterpreted the question. I wish I knew why,
but I'm starting to suspect that others do not have a framework in
which they could easily understand my actual questions. I'm starting
to see that those who understand my questions are the ones who do not
get angry with me.

If you have any interest in doing me a favor, Tony, I would really,
really appreciate it if you could try to understand what I am asking
and let me know if you are getting closer to understanding that. It is
no doubt an ignorant question but I'm quite sure it is not a stupid
question. Let me know if you are getting any closer to seeing that.

Thanks. --dawn

[Keith H Duggar]

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? Nobody has
said that. You are putting words into my mouth and creating
a false dichotomy (yet another logical fallacy). 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).

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?

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

> 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. In any case, I now know this is quite
off-topic here so we should not discuss this in cdt any
longer. Perhaps you should open a thread in comp.programming
to discuss the general advantages of fixed-length data.

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

> I think I have even seen a counter-example.

Yes, false dichotomy and sophistry is useful in this way.

> [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. As to "why" how can one ever know
the motivations of another? I would suggest asking them (the
implementors) or checking for technical papers documenting
their design choices. 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.

> 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. Others have stated
this is simply a hallucination. Do you have any DATA on the
matter?

(Wait, I just recalled I used FileMaker Pro quite a bit some
years ago. I NEVER input any size constraints. Is FileMaker
an RDBMS? If so does this demolish your generalization?)

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?

-- Keith --

[mAsterdam]

paul c wrote:
> mAsterdam wrote:
>
>> ...
>>
>> I'ld welcome those professionals - I would like to see
>> some other perspectives. Anybody seriously considering
>> to contribute from outside the RM will start reading
>> some recent posts and suspect that they will not be
>> treated politely, though. Not very attractive.
>> ...
>
>
> The thing is, saying "i've got this system that goes 'up' when i press
> this button and goes 'down' when i press that button" isn't nearly
> enough to qualify for discussion, no matter who the "professional" is.

By itself I can completely agree with this remark.
Triggerred, as it is, by the phrase "contribute from
outside the RM" it shows a hostile attitude towards all
topics except RM.

> What was remarkable for me about the rm was that it found very precise
> parallels (maybe analogues is a better word, but metaphor is too sloppy
> a word) that allowed one to make a machine interpretation of an
> established mental system, both predictable as far as Turing, Godel et
> cetera allow.

"machine interpretation of an established mental system" is a
very interesting topic. There may be very interesting observations
from disciplines outside the realm of CS - even if they don't
know a thing about RM. They won't get very far communicating these
observations here, because everything in their posts at even the
sligthest potential tension with the RM will immediately be
focussed upon at the cost of the bigger picture.

> I think the people who propose alternatives need to
> establish the same connection before they start throwing new operators
> and metaphors around.

New from which perspective? Somebody who doesn't know to distinguish
between SQL-dbms and RDBMS isn't necessarily busy
proposing an alternative to the RM - but he will very rapidly
appear to be as if he is after the "discussion" starts and
his RM-ignorance is amplified.

[dawn]

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

[mAsterdam]

Keith H Duggar wrote:
> mAsterdam wrote:
>

>>It takes more stamina to show ignorance in this newsgroup
>>now, than it did say a year ago. I have recently refrained
>>from asking questions revealing ignorance because of
>>anticipated reactions here - even when it would just be
>>about exact wording.
>
>
> Strange, not my experience here at all. I dropped by a few
> weeks ago, readily admitted I was ignorant, participated a
> little, asked some questions, and was treated VERY
> well. When asking database related questions I tried to do
> so with humility and was not vociferous. Could this have
> been a factor in my treatment?

Yes, I think so.

But it also helped, that you are very willing to accept
the RM - even thought you do have some gaps in your
knowledge about it - no problem for you here, a few
months of reading will help you putting it in perspective.

The point is that if you weren't very willing to accept
the RM, my guess is you would not be treated as well, even
if you would have been as humble as you were/are.

(BTW I don't even know what "vociferous" means.
Because I only saw it in belittling utterances
I didn't bother to look it up).

You weren't humble towards dawn. Could her bullying
by several posters here been a factor in that?

Here is the stuff I recently refrained from asking new
questions about:

http://groups.google.nl/group/comp.databases.theory/browse_frm/thread/cb53085682aff78c/09b9ce71fe8c978e?lnk=st&q=UP+hierarchy+constraint&rnum=1&hl=nl#09b9ce71fe8c978e

http://groups.google.nl/group/comp.databases.theory/tree/browse_frm/thread/676ba4129c98e98e/2740b7f0547e797f?rnum=1&q=C3+MRO&_done=%2Fgroup%2Fcomp.databases.theory%2Fbrowse_frm%2Fthread%2F676ba4129c98e98e%2F2740b7f0547e797f%3Fq%3DC3+MRO%26rnum%3D1%26#doc_2740b7f0547e797f

> Perhaps your hesitancy has more to do with personal pride?

Not really (I think). More the anticipation of an uphill
battle of answering a lot of traps disguised as questions.

> If so you could create an alternate google account (I would
> go for "y" to match up with "x") and post questions using
> that account.

Actually "x" has pointed out several of my mistakes.

> Perhaps you will discover good treatment and
> relax enough to post questions from you main account.

Heh. I suspect regular readers would uncover my disguise
almost immediately. Faking is one of the basic human skills
I am not good at.

[Tony D]

Dawn wrote :

> That I know. That does not answer my question. I fully understand
> that one need not specify max length constraints if implementing only
> "in theory." I wondered if there were anything in the theory that
> might prompt implementations that have, perhaps as a side-effect, the
> need for or advantage when individual attributes are specified with max
> length constraints.

If you know that, then you know the answer to your question, which
means there was no need to ask it, which makes it a silly question.
I'll say it again: the relational model is orthogonal to type. That
means the relational model makes no demands and imposes no restrictions
on the types available (apart from the obvious requirement for a
boolean type). It really is that simple. There really is nothing to see
here.

> It hesitate to report that I still don't know the answer to my
> question, but I will research it differently and see if I can get
> further.

I think you do know the answer to your question, but the penny isn't
dropping.

> It actually thought it would have a simple answer and that
> someone would have that answer handy enough to pass it along, but it
> seems you and others misinterpreted the question.

It does have a simple answer. That simple answer has been given on
several occasions. Perhaps equally you aren't understanding or are
misinterpreting that simple answer ?

> I wish I knew why, but I'm starting to suspect that others do not have a framework in
> which they could easily understand my actual questions.

This sentence is perhaps more educational than you truly intended.

> I'm starting to see that those who understand my questions are the ones who do not
> get angry with me.

Who's angry ? I'm certainly not; I'm not even exasperated at having
seen a simple question answered simply by several people, yet you still
don't seem to "get it". Ho-hum.

> If you have any interest in doing me a favor, Tony, I would really,
> really appreciate it if you could try to understand what I am asking
> and let me know if you are getting closer to understanding that.

I think I understand well enough what you're asking. I will, at risk of
muddying the waters considerably, suggest that you read up on the
language Euler, which was invented by Niklaus Wirth, and consider the
difference between the proposed language and the language that was
actually implemented; or, consider the difference between the Algol-68
report's definition of modes and the implementation that most compilers
actually managed. This might help put the difference between what a
model proposes and what implementers implement (and why) into
perspective.

> It is no doubt an ignorant question but I'm quite sure it is not a stupid
> question.

I would suggest "irrelevant" and "unnecessary" as alternatives to
"stupid". Or just plain "silly".

- Tony

[Alfredo Novoa]

Keith wrote:

>The performance advantages of size constraints is
>fundamental.

Only with lazy implementations.

Regards
Alfredo

[mAsterdam]

Tony D wrote:

> At time of this writing, my version of something approaching a
> reasonable response is at post number 49 on the Google list.

Why the hide and seek?

Is there a way to find out from this which post it is you referred to?

[dawn]

Tony D wrote:
> Dawn wrote :
>
> > That I know. That does not answer my question. I fully understand
> > that one need not specify max length constraints if implementing only
> > "in theory." I wondered if there were anything in the theory that
> > might prompt implementations that have, perhaps as a side-effect, the
> > need for or advantage when individual attributes are specified with max
> > length constraints.
>
> If you know that, then you know the answer to your question,

If I know it, I don't know that I know it.

> which
> means there was no need to ask it,

I wanted to know the answer and still do

> which makes it a silly question.
> I'll say it again: the relational model is orthogonal to type.

I can say that too. That is not my question. My question cannot be
answered within the theory, it requires straddling theory (which one
could see as one grouping of requirements for a DBMS product) and
application of the theory. Requirements do not dictate design, but
they can encourage different aspects of design. The simplest design to
meet a set of requirements might lead us to select this feature or
constraint in a system. If we add in a requirement that such a feature
or constraint should not be there, then the design would be different.

So, maybe (and I really don't know) the RM as a set of requirements
leads to a design where max length constraints on attributes are the
easiest way to implement these requirements. So, if we don't add in
the requirement that we do not want any penalty for variable length
attributes, tossing that in wtih our RM requirements, then we are most
likely to end up with the fixed max lengths.

Did that make any sense?

> That
> means the relational model makes no demands and imposes no restrictions
> on the types available (apart from the obvious requirement for a
> boolean type). It really is that simple. There really is nothing to see
> here.
>
> > It hesitate to report that I still don't know the answer to my
> > question, but I will research it differently and see if I can get
> > further.
>
> I think you do know the answer to your question, but the penny isn't
> dropping.

It is possible, but until I know I know it, I don't know it.

> > It actually thought it would have a simple answer and that
> > someone would have that answer handy enough to pass it along, but it
> > seems you and others misinterpreted the question.
>
> It does have a simple answer. That simple answer has been given on
> several occasions. Perhaps equally you aren't understanding or are
> misinterpreting that simple answer ?
>
> > I wish I knew why, but I'm starting to suspect that others do not have a framework in
> > which they could easily understand my actual questions.
>
> This sentence is perhaps more educational than you truly intended.

I don't know how you took it, but I know that I do not have the same
background as most of the cdp readers and writers, given that I do not
have a degree in CS and have never been a DBA. I have also spent far
more hours and years working with non-SQL DBMS's than SQL DBMS's,
although I have a little experience as well as reading knowledge of the
latter. So, I know I have to figure out how to ask questions in the
language most likely to be understood so my questions can be answered
or opinions interpreted correctly (I'm clearly failing at this right
now). But perhaps this question has an additional problem. It might
be the case that whatever framework (combination of terms, experience,
and perspective) I am using that leads me to such a question is not one
that is common nor would it be easy for someone without a similar
framework to understand. So, it gets interpreted incorrectly.

> > I'm starting to see that those who understand my questions are the ones who do not
> > get angry with me.
>
> Who's angry ? I'm certainly not;

Good. Thanks.

> I'm not even exasperated at having
> seen a simple question answered simply by several people, yet you still
> don't seem to "get it". Ho-hum.
>
> > If you have any interest in doing me a favor, Tony, I would really,
> > really appreciate it if you could try to understand what I am asking
> > and let me know if you are getting closer to understanding that.
>
> I think I understand well enough what you're asking. I will, at risk of
> muddying the waters considerably, suggest that you read up on the
> language Euler, which was invented by Niklaus Wirth, and consider the
> difference between the proposed language and the language that was
> actually implemented;

I am familiar with Euler. I don't see the connection.

> or, consider the difference between the Algol-68
> report's definition of modes and the implementation that most compilers
> actually managed.

This is a different issue, it seems. This might be relevanant to the
fact that there is no pure implementation of the RM. I'll need more
clues if you really think this is relevant to my question.

> This might help put the difference between what a
> model proposes and what implementers implement (and why) into
> perspective.

I find such stories interesting, and I can see some relevance to the
topic, but this will not answer my question. I have no doubt at all
that the RM does not dictate that every attribute have a max length
constraint. I'm wondering if there are requirements that drive
decisions in this area when implementing the RM where those vendors not
starting with the RM in their original requirements might not have been
driven to similar decisions.

> > It is no doubt an ignorant question but I'm quite sure it is not a stupid
> > question.
>
> I would suggest "irrelevant" and "unnecessary" as alternatives to
> "stupid". Or just plain "silly".

Am I getting any better at explaining my question or am I still getting
nowhere? --dawn

[Keith H Duggar]

mAsterdam wrote:
> Keith H Duggar wrote:
> > mAsterdam wrote:
> > >It takes more stamina to show ignorance in this
> > >newsgroup now, than it did say a year ago. I have
> > >recently refrained from asking questions revealing
> > >ignorance because of anticipated reactions here - even
> > >when it would just be about exact wording.
> >
> > Strange, not my experience here at all. I dropped by a
> > few weeks ago, readily admitted I was ignorant,
> > participated a little, asked some questions, and was
> > treated VERY well. When asking database related
> > questions I tried to do so with humility and was not
> > vociferous. Could this have been a factor in my
> > treatment?
>

> But it also helped, that you are very willing to accept
> the RM - even thought you do have some gaps in your
> knowledge about it - no problem for you here, a few months
> of reading will help you putting it in perspective.
>
> The point is that if you weren't very willing to accept
> the RM, my guess is you would not be treated as well, even
> if you would have been as humble as you were/are.

I understand what you are saying. However (and this is
really key) "accept" is inaccurate. It is not that I
willingly accept the RM. What one ultimately accepts as
true, how that changes from day to day, how one employs
those beliefs in their work, etc, is a personal matter that
is largely irrelevant (to cdt discourse I mean).

What does matter is that one is willing to politely ask,
listen, and try to comprehend the arguments of /others/. In
other words, for achieving efficient polite discourse,
/internal/ acceptance is far less important than /external/
openness.

[warning : only dusk-til-dawn stuff remains below]

> You weren't humble towards dawn.

I won't deny this. Though I never claimed that I was. I only
claimed that "When asking database related questions I tried
to do so with humility". Most of my DW interaction so far
has been related to logic (as in reasoning) and recently (in
this thread) general implementation issues that are not
"database related".

> Could her bullying by several posters here been a factor
> in that?

No, this was not a factor. Rather statements such as these
from the first post of her's I read:

"I just did a talk where I argued that [Codd] took what
was logically good thinking and then made a key statement
of religious zeal that we have been living with for
decades now." -- DW

"I'd suggest that it is time to abandon ... the relational
model" -- DW

"I have a master's degree in mathetmatics, and it seems to
me that Codd's use of simple relations for persisting
language propositions is flawed at its core."

"It's time to kill the relational model and gain some
agility back into the development process" -- DW

Frankly put, that was unacceptable unmitigated /arrogance/.
Especially for someone new to the community as she stated:

"Since I have not spoken in this forum before ..." -- DW

And to this day her posts still exude arrogance and
sophistry. And even when a basic logical fallacy is pointed
out with a clear precise example:

KHD wrote :
> DW wrote :

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

> said that. You are putting words into my mouth and creating

> a false dichotomy (yet another logical fallacy). 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.
>

> KHD wrote :

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

she fails to recognize the fallacy, fails to recognize that
putting words in another's mouth is rude, and instead blames
it on my "understanding" and "resonance".

DW wrote:
> 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 ... 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.

And, to cap it off, see later pushes the responsibility on ME
to "adjust" HER statements:

DW wrote :
> KHD wrote :
> > DW wrote :
> > > I do not 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.

ridiculous! Perhaps one of her first statements in cdt is
/literally/ true

"... I'm becoming passionate about this subject and
decided to start making noise." -- DW

Passionate? And then this self-confessed "passionate"
accuses other people (even to this day, Codd included) of
religious fundamentalism? Astounding! "Noise" truly!

Back to the "accept" point. If DW came here, asked questions
politely and carefully without flame bait, /listened/ to
others, /tried/ to remain /open/ and /comprehend/, and then
decided not /accept/ any of the arguments she heard and went
over to the c.d.pick forum and ranted all day about the
irrational "religious" c.d.t folks are, probably nobody
would care! And she would have had a good experience I
bet. But instead she /began/ her experience here by posting
(in cdt) the stuff quoted above; simply seems unacceptable;
and she (and perhaps the community) has paid the price ever
since.

-- Keith --

[Tony Andrews]

dawn wrote:
> Tony D wrote:
> > given that the premise it starts from is thoroughly discounted in at
> > least one of the books Dawn claims to have read,

>
> I read 'em, but didn't memorize 'em, feel free to point me to a page
> number that answers my question.

There is no such page, apparently. You have said elsewhere in this
thread that you know that:

> > "The reason I say the ideas of object-oriented (at least the good ones)
> > are orthogonal to the ideas of the relational model is that *nowhere
> > does the relational model prescribe what data types you have*."

You said:

> That I know. That does not answer my question.

So it is clear that you DO know that there is nothing in RM that would
require a DBMS to implement length constraints on attributes, yet you
continue to deny that you know it.

Your question seems to boil down to: why *can* you constraint the
length of strings in a SQL DBMS but you *can't* in an MV DBMS?

It seems a bit like asking "why does car X offer climate control while
car Y doesn't? What is it about car X that makes it /need/ climate
control while car Y doesn't".

Your serif / sans-serif analogy doesn't make sense either. SQL DBMSs
don't impose length constraints on columns "by default". In each and
every case the constraint is specified by the person creating the
table. If it did impose them by default then presumably columns would
tend to all have the same length constraint, e.g. 50, whereas a cursory
glance at a typical database shows lots of different length constraints
being used.

[x]

"Keith H Duggar" <dug...@alum.mit.edu> wrote in message
news:1148860282.2...@38g2000cwa.googlegroups.com...

> mAsterdam wrote:
> > dawn wrote:
> > > If people want to tell me how ignorant I am, I don't
> > > mind agreeing.
>
> Are you honestly sure about that?
>
> > > I have anecdotal, but not scientific, evidence that men
> > > are less inclined to admit ignorance or even to show it
> > > with their questions.

> Even if that generalization were true (I'm a man and
> /readily/ admit ignorance and accept superior reasoning when
> it is demonstrated), how is it relevant to this discussion?
> Why do you keep bringing up irrelevant facts such as your
> gender, the house your daughter owns, the awards the other
> received, etc? Do you /want/ us to pigeonhole you as an
> irrational emotional hormonal woman?

Some men are likely to call women 'irrational' :-)

> > It takes more stamina to show ignorance in this newsgroup
> > now, than it did say a year ago. I have recently refrained
> > from asking questions revealing ignorance because of
> > anticipated reactions here - even when it would just be
> > about exact wording.

> Strange, not my experience here at all. I dropped by a few
> weeks ago, readily admitted I was ignorant, participated a
> little, asked some questions, and was treated VERY
> well. When asking database related questions I tried to do
> so with humility and was not vociferous. Could this have
> been a factor in my treatment?

> Perhaps your hesitancy has more to do with personal pride?
> If so you could create an alternate google account (I would
> go for "y" to match up with "x") and post questions using
> that account. Perhaps you will discover good treatment and
> relax enough to post questions from you main account.

Funny. 'Y' is the first word I said when I arrived on this world.
The reply was WOW, I was told.
Over the years, the reply became 'because'. :-)

[Erwin]

"logical variaibility"

Dawn,

No matter how you toss or turn it, if you design/define a database you
*WILL HAVE TO* answer the "range" question for each and every
individual attribute in your database. Is 50 ft a possible length for
a human person to have ? Is 800 pounds a possible weight for a person
? Is a first name consisting of 1234 tokens a possible first name for
a person ? Is a 26-character string a possible zip code in a foreign
address ?

At the logical level, which you claim your question is about, string
lengths are just a specific appearance of the more general "What's the
domain of valid values" question.

[Bob Badour]

Alfredo Novoa wrote:
> Keith wrote:
>
>>The performance advantages of size constraints is
>>fundamental.
>
> Only with lazy implementations.

Alfredo, the performance advantages of size constraints are fundamental
regardless--as are the performance disadvantages.

The problem with lazy implementations is they tend to force one way or
the other, which reduces choice and ultimately reduces physical
independence.

[Bob Badour]

Keith H Duggar wrote:

> dawn wrote:
>
>>Keith H Duggar wrote:
>>
>>>dawn wrote:
>>>

[very insightful analysis of Dawn's sophistry snipped]

> Stop it Dawn! More of this "must" and "important" crap false
> dichotomy.
>
>>I think I have even seen a counter-example.
>
> Yes, false dichotomy and sophistry is useful in this way.
>
>
>>[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?

The answer to "if" is no. Those implementing DBMS's stemming from the RM
neither tend to nor always write such DBMS tools. Dawn is a
self-aggrandizing ignorant. This straw man she constructed has been
explained away a dozen times already.

Because the answer to "if" is no, "why" does not even apply in the first
place.

> As to "if" I have no idea. As to "why" how can one ever know
> the motivations of another? I would suggest asking them (the
> implementors) or checking for technical papers documenting
> their design choices. 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.

Keith, I respectfully point out that you are playing into Dawn's hand by
pretending to have a dialogue with her. She is a self-aggrandizing
ignorant with an axe to grind. You treat her as if she is sincere, which
just gives her more opportunity to shovel truckloads of horseshit. She
is manipulating you into a monologue so she can ride along and claim
credit for it.

You have already noticed that her arguments are pointless sophistry.
Pointless, that is, if intended to pursuade intelligent, educated people
with the time to digest what she wrote.

She does not participate here to pursuade such people. Her only goal is
to baffle with bullshit those who lack either the education or the time
to catch her in her sophistry.

The coup de grace will come when she blames you for her own incapacity
and unwillingness to understand simple english.

It's much more effective to just point out that she is a
self-aggrandizing ignorant trying to sell snake oil to an unsuspecting
public and leave it at that.

Beyond giving Dawn a platform from which to shill her substandard and
potentially dangerous wares, your continued interraction with her wastes
everyone's time.

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

No, it is not a correct observation. Has that not been made sufficiently
clear yet? Even an eight year old can understand and accept no the first
time.

> I have no experience with DBMS products. Others have stated
> this is simply a hallucination. Do you have any DATA on the
> matter?
>
> (Wait, I just recalled I used FileMaker Pro quite a bit some
> years ago. I NEVER input any size constraints. Is FileMaker
> an RDBMS? If so does this demolish your generalization?)

FileMaker is a file processor and not a DBMS just as Pick is a file
processor and not a DBMS. However, I suspect as far as file processors
go, FileMaker is probably closer to relational than Pick will ever be.

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

Self-aggrandizing ignorants try to claim credit whereever and whenever
they can.

[Bob Badour]

Keith H Duggar wrote:
> mAsterdam wrote:
>
>>Keith H Duggar wrote:
>>
>>>mAsterdam wrote:
>>>
>>>>It takes more stamina to show ignorance in this
>>>>newsgroup now, than it did say a year ago. I have
>>>>recently refrained from asking questions revealing
>>>>ignorance because of anticipated reactions here - even
>>>>when it would just be about exact wording.
>>>
>>>Strange, not my experience here at all. I dropped by a
>>>few weeks ago, readily admitted I was ignorant,
>>>participated a little, asked some questions, and was
>>>treated VERY well. When asking database related
>>>questions I tried to do so with humility and was not
>>>vociferous. Could this have been a factor in my
>>>treatment?
>>
>>But it also helped, that you are very willing to accept
>>the RM - even thought you do have some gaps in your
>>knowledge about it - no problem for you here, a few months
>>of reading will help you putting it in perspective.
>>
>>The point is that if you weren't very willing to accept
>>the RM, my guess is you would not be treated as well, even
>>if you would have been as humble as you were/are.

Please note the important distinction between "not willing to accept"
and "having not yet accepted". The first is the very definition of
closed-minded while the second indicates mere skepticism.

One cannot be simultaneously closed-minded and humble. Closed-mindedness
is not only arrogant but rude and disrespectful in that it wastes the
time of everyone else. mAsterdam seems to think he can be rude to
everyone here and that no one should ever have the temerity to note the
rudeness.

Bollocks on that!

> I understand what you are saying. However (and this is
> really key) "accept" is inaccurate. It is not that I
> willingly accept the RM. What one ultimately accepts as
> true, how that changes from day to day, how one employs
> those beliefs in their work, etc, is a personal matter that
> is largely irrelevant (to cdt discourse I mean).

Actually, the key word in the phrase is "willing". Whether one has or
has not accepted a particular point of view, if one is unwilling to
accept different points of view, one is closed-minded and frankly lacks
intellectual honesty.

Having twit-filtered mAsterdam for intellectually dishonest
closed-mindedness and for wasting people's time, his phraseology comes
as no surprise to me at all.

Even with this explanation, I don't expect him to get it.

> What does matter is that one is willing to politely ask,
> listen, and try to comprehend the arguments of /others/. In
> other words, for achieving efficient polite discourse,
> /internal/ acceptance is far less important than /external/
> openness.
>
> [warning : only dusk-til-dawn stuff remains below]
>
>>You weren't humble towards dawn.
>
> I won't deny this. Though I never claimed that I was. I only
> claimed that "When asking database related questions I tried
> to do so with humility". Most of my DW interaction so far
> has been related to logic (as in reasoning) and recently (in
> this thread) general implementation issues that are not
> "database related".
>
>
>>Could her bullying by several posters here been a factor
>>in that?

I find it interesting who mAsterdam perceives are the bullies.

Picture a scene at a wedding reception where one of the guests is a
self-indulgent drunk who pushes her way onto the stage, grabs the
microphone and proceeds to 'perform' a 'comedy' routine comprising a
series of uninteresting bigoted jokes that are sure to offend the
inlaws. When the self-indulgent drunk does not get the applause she
demands, she blames the other guests for not understanding the jokes.

In mAsterdam's world, the bully is the person who says: "You are drunk
and rude, and you are making everyone uncomfortable. Put down the mike
and get off the stage."

The self-aggrandizing ignorants are self-indulgent, disrespectful, rude,
and they insist on shoving their way to where they do not belong. Are
those not the acts of bullies?

Actually, there is a deeper logical fallacy that you missed. Her
original question is a loaded question.

When you come to accept that Dawn is nothing more than a
self-aggrandizing ignorant, you will understand why she used that
particular sophistry. She has no interest in learning the answer to a
question.

She wants only to promote a meme and that meme is described by the false
axiom that loads her question. The more she manipulates you into
discussing the question, the more times the meme gets repeated.

Eventually, a gross misconception gains wide acceptance while the retard
claims credit for exposing the 'problem'. A problem that never was!

In this way, the self-aggrandizing ignorants spread misconception and
ignorance for their own benefit and at great harm to this entire field.
A much more effective response to her is to note that she is a
self-aggrandizing ignorant, to tell her to piss off and to stop wasting
everyone's time.

> DW wrote:
>
>>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 ... 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.

Ahhh... the coup de grace! Now, the self-aggrandizing ignorant claims
the high-ground by dismissing you as too stupid to understand her
question. A question that you clearly understood on its face.

She counted on you to give her the benefit of any doubt no matter how
small, which you did, to manipulate you to her own ends. Finally, she
repaid you by implying you are stupid.

In the end, was she worth the effort you put into her?

[snip]

[Bob Badour]

Tony D wrote:

> Dawn wrote :
>

>>I wish I knew why, but I'm starting to suspect that others do not have a framework in
>>which they could easily understand my actual questions.
>
> This sentence is perhaps more educational than you truly intended.

Framework:
logic

Understanding:
see "loaded question", "fallacy of many questions", "presupposition"

Dawn has no interest in answering a question. She is interested in
spreading a misconception as expressed in her presupposition.

>>It is no doubt an ignorant question but I'm quite sure it is not a stupid
>>question.

It's not the question that is stupid. It's the person asking it who is.

[Tony D]

Dawn wrote :

> If I know it, I don't know that I know it.

Eventually, the penny will drop. The question is, will you wait for
gravity to exert its pull, or do a little extra reading up to help it
on its way ?

> It is possible, but until I know I know it, I don't know it.

A "point of seeing" is a process.

> I don't know how you took it, but I know that I do not have the same
> background as most of the cdp readers and writers, given that I do not
> have a degree in CS and have never been a DBA.

The one good thing about formal computing science is learning to look
at the theory first, then consider various implementations separately.
Once in this habit or world view, it becomes not quite instinctual, but
reasonably straightforward. Without this habit, however acquired, it
becomes difficult to maintain a proper separation between issues with
theory and issues with implementations. Sadly, this seems to have
become expendable in degree curricula over the last few years.

> It might be the case that whatever framework (combination of terms, experience,
> and perspective) I am using that leads me to such a question is not one
> that is common nor would it be easy for someone without a similar
> framework to understand.

Or perhaps the framework is broken, and needs repair ? It's by
absolutely no means impossible, but it's a bit more work without a
formal background. (God alone knows how, but I managed to miss
databases completely in my degree, so I have to pedal quite a bit
harder to keep up sometimes than I really should have to.)

The relevance of Euler and Algol-68 was to point out the gap between
what was designed or proposed, and what eventually gets implemented -
although, especially in the case of Algol-68, it was a formal design
that more than a few implementations simply didn't follow. You have to
remember that Codd explicitly didn't say anything about physical
representation, and very little about types (apart from an unfortunate
use of the word "atomic"), so the relational model was pretty much at
the mercy of whoever implemented it - or as happened, on some crucial
issues grabbed the wrong end of the stick and shook it hard. It appears
that both IBM & Ingres chose a disk image method of representing
tables. (There may also have been a touch of the Fortran syndrome - "we
didn't know we were designing a language - we were just writing a
compiler to prove you could".)

The sad part is that no-one seems to have gone much beyond the disk
image method of representing tables (unless you count TRM, which is a
subject kicked to death on another thread recently).

- Tony

[Tony D]

No hide and seek; merely referencing a post I had already written which
it looked like Dawn hadn't read yet. It's now post 72 in the Google
tree view, in response to the original posting.

[David Cressey]

"dawn" <dawnwo...@gmail.com> wrote in message
news:1148773922.2...@j55g2000cwa.googlegroups.com...
> [OK, here is my next "stupid question" as I cut a path in my study of
> the RM. Those teachers who just want to tell this student how ignorant
> she is are welcome to sit this out as I really am hoping to
> understand.]
>
> In SQL-DBMS's, like VSAM (and other indexed sequential files before
> them) a lot of attributes are specified with max length constraints.
> While there are some attributes where this constraint is related to a
> conceptual constraint (from the analysis phase), these lengths are
> often introduced for the logical model or implemenation in the DBMS.

Is VSAM really a DBMS? I looked up VSAM in wikipedia, and the definition I
found suggests that VSAM is NOT a DBMS, although both IMS and DB2 are
layered upon it.

In the world of DEC, which I know better, both Rdb/VMS and VAX DBMS were
layered on KODA. KODA was not a DBMS but a useful building block.

Is VSAM really bound to SQL as an interface language?

I'd like to nail this down before I deal with the original question.

[Bob Badour]

Tony D wrote:

> Dawn wrote :
>
>>If I know it, I don't know that I know it.
>
> Eventually, the penny will drop.

You give the self-aggrandizing ignorant far more than her due.

>>I don't know how you took it, but I know that I do not have the same
>>background as most of the cdp readers and writers, given that I do not
>>have a degree in CS and have never been a DBA.
>
> The one good thing about formal computing science is learning to look
> at the theory first, then consider various implementations separately.

Remember this idiot claims to have a degree in mathematics. If she
doesn't comprehend the benefit of theory, then she is just too stupid
for words, and whatever institution she conned into granting her a
degree ought to yank it right back again out of shame for having granted it.

>>It might be the case that whatever framework (combination of terms, experience,
>>and perspective) I am using that leads me to such a question is not one
>>that is common nor would it be easy for someone without a similar
>>framework to understand.

The self-aggrandizing ignorant flatters herself.

[the part where you were taken in by autoflattery snipped]

[David Cressey]

"Tony D" <tonyis...@netscape.net> wrote in message
news:1148915599....@y43g2000cwc.googlegroups.com...

> The sad part is that no-one seems to have gone much beyond the disk
> image method of representing tables (unless you count TRM, which is a
> subject kicked to death on another thread recently).

I don't understand the term "disk image method of representing tables".

Are you referring to some sort of "virtual records storage system" where
each record represents a row of a table?
Or is it something different?

Didn't Firebird implement tables quite differently?

[Roy Hann]

"Tony D" <tonyis...@netscape.net> wrote in message
news:1148915599....@y43g2000cwc.googlegroups.com...

> You have to
> remember that Codd explicitly didn't say anything about physical
> representation, and very little about types (apart from an unfortunate
> use of the word "atomic

I don't think his use of the term "atomic" was in any way unfortunate. It
is hard to think of a better word. It very clearly conveys what was surely
his intention, which was: whatever value appears at the intersection of a
row and a column will be treated as if it has no internal structure.

What is unfortunate is that he left us to infer his intended meaning rather
than stating it explicitly, so a great deal of superstition and folklore has
sprung up in the the gap.

Roy

[Tony D]

Basically, there is a very direct mapping between what you put in the
"create table" command and the collection of bytes that appear on a
disk drive. If you were to have a table like this

create table mytable(
c1 integer,
c2 char(5)
);

On disk you would very probably have a series of about 11 bytes (4
bytes for the integer + 1 to indicate whether it is null or not, plus 5
bytes for the characters + 1 to indicate if it is null or not), plus
probably 4 (or more) bytes as an internal row or tuple identifier. (The
DBMS may additional management info as well.) For quite a few DBMS
products, you could, if sufficiently willing, sit with an octal dump
and reverse engineer the database schema from the byte sequences very
straightforwardly - the enemy would be time and effort, rather than
difficulty.

This is probably the most simple and straightforward way of putting
this info on disk, but not necessarily the most efficient for all
operations. But hey, you can index it, right ? :)

I don't know the Firebird/Interbase systems, so I can't comment on
those.

- Tony

[Tony D]

Roy wrote :

> What is unfortunate is that he left us to infer his intended meaning
> rather than stating it explicitly, so a great deal of superstition and
> folklore has sprung up in the the gap.

That's what I was fumbling towards. I can't think offhand of a better
word either - even "scalar" can still cause arguments.

- Tony

[paul c]

David Cressey wrote:
> "dawn" <dawnwo...@gmail.com> wrote in message
> news:1148773922.2...@j55g2000cwa.googlegroups.com...
>
>>[OK, here is my next "stupid question" as I cut a path in my study of
>>the RM. Those teachers who just want to tell this student how ignorant
>>she is are welcome to sit this out as I really am hoping to
>>understand.]
>>
>>In SQL-DBMS's, like VSAM (and other indexed sequential files before
>>them) a lot of attributes are specified with max length constraints.
>>While there are some attributes where this constraint is related to a
>>conceptual constraint (from the analysis phase), these lengths are
>>often introduced for the logical model or implemenation in the DBMS.
>
>
> Is VSAM really a DBMS? I looked up VSAM in wikipedia, and the definition I
> found suggests that VSAM is NOT a DBMS, although both IMS and DB2 are
> layered upon it.

> ...

no, it's not a DBMS. let me see if i can test what little memory i have
left. others could give a more technical explanation but from using it
up 'til about ten years ago and supporting it from time to time, from
the programmer's point of view it was merely an access method /file
system and mostly invisible to users (invisible in a way that most dbms
could never be). it was also used to implement a system 'catalog' by
several IBM os's but not in the sense of a dbms catalog more as a way to
keep track of what files were on what disks. it had verbs like get, put
(sequential access), read, write (random and keyed access). you'd open
and close each file individually and usually also specify whether you
were going to update it, in which case other users couldn't share it.
record access was one-at-a-time referring always to the file
handles/control blocks that were obtained at open time. files were
usually 'defined' in terms of record lengths using the arcane interfaces
that came with OS/MVS/DOSVS and so forth, such as JCL, clists. there
was no notion of combining records or files other than at a file level
such as concatenation. this was often done with the obscurely-named
utility programs that came with those OS'es.

there were three forms of file organization, a sequential one where
entry order was preserved, a random one you supplied a record number and
a keyed one that was based on a dense btree. these forms continued the
three basic access methods that the first System 360's used (ISAM, QSAM
and BDAM) but the btree-style index was an improvement over ISAM which
was tightly coupled with IBM's disk and programmable controller design
that had some hardware support for physical 'key' records that the
hardware actually distinguised from 'data' records. that was part and
parcel of the early IBM approach to achieving IO and CPU overlap by
letting a programmer off-load disk cylinder searches to the disk
controller.

starting in the late 1960's, IBM pushed VSAM hard, partly by putting it
underneath IMS. part of the reason must have been to discourage the
older access methods which were even more closely tied to hardware -
disk vtocs - "volume table of contents" that were much more hw-specific
than the directories we see in the popular os'es today. i could be
wrong, but i believe the system R people built on top of it too because
it was familiar. it became virtually impossible to package MVS and most
of the other 'program products' without including VSAM in your monthly
license fees.

from a programmer's point of view i think it's fair to say that vsam is
comparable, say, to a commercial package such as one whose name i think
was 'btrieve' or somesuch. really just a low-level doorway to disk drives.

> In the world of DEC, which I know better, both Rdb/VMS and VAX DBMS were
> layered on KODA. KODA was not a DBMS but a useful building block.

> ...

around 1990 i had to make some drivers to talk to Dec's (VMS) access
method. i don't remember what it was called but i was very impressed
with it, granted as a mere file system. it had everything VSAM had,
plus transactions at a file level. but it was still nothing more than
a file system, no notion of 'columns' or 'attributes' in the dbms sense
and appl'n programs had to map the files byte by byte.

> Is VSAM really bound to SQL as an interface language?

> ...

since there are SQL's that run on systems that don't have VSAM, i'd say no.

> I'd like to nail this down before I deal with the original question.

> ...

good luck, i think it's just one more red herring.

p

[alfr...@gmail.com]

Roy wrote:

>I don't think his use of the term "atomic" was in any way unfortunate. It
>is hard to think of a better word. It very clearly conveys what was surely
>his intention, which was: whatever value appears at the intersection of a
>row and a column will be treated as if it has no internal structure.

The problem is that he wrote "atomic" instead of "treated as it were
atomic".

Regards

[Marshall]

Bob Badour wrote:
> Alfredo Novoa wrote:
> > Keith wrote:
> >
> >>The performance advantages of size constraints is
> >>fundamental.
> >
> > Only with lazy implementations.
>
> Alfredo, the performance advantages of size constraints are fundamental
> regardless--as are the performance disadvantages.

It seems to me that the integrity-enforcement value of a max
length well exceeds the performance value.

The performance value doesn't seem so great to me. The one
circumstance in which it would seem more than trivial would be
where the dbms could store a varchar inline with the rest of
the fields, vs. in a separate heap. (But I know virtually nothing
about database internals, so I could be way off.) That seems
like it would be a significant win.

But at least some DBMSs have separate varchar types for
2^8 chars, 2^16, 2^24, and 2^32. I don't see much of a win
in doing so. The one advantage I can imagine for this would
be being able to use smaller pointers/offsets, which would
then use less storage. But I don't see where a dbms would
need to be storing pointers/offsets into a varchar, so wtf?
And if we are talking about the implementation of library
code for functions on varchars, I'd expect them all to use
32 bit pointers for traversing the attribute value, regardless
of the max size of the type.

Another, unrelated point that hasn't been mentioned so far
(although I might have missed it; thread fatigue setting in...)
is that in fact, a variety of non-mandatory performance tuning
options is an indicator of technical *maturity* of a product, and
we might well ask why another product or family of products
*didn't* have such.

Marshall

[dawn]

Tony Andrews wrote:
> dawn wrote:
> > Tony D wrote:
> > > given that the premise it starts from is thoroughly discounted in at
> > > least one of the books Dawn claims to have read,
> >
> > I read 'em, but didn't memorize 'em, feel free to point me to a page
> > number that answers my question.
>
> There is no such page, apparently. You have said elsewhere in this
> thread that you know that:
>
> > > "The reason I say the ideas of object-oriented (at least the good ones)
> > > are orthogonal to the ideas of the relational model is that *nowhere
> > > does the relational model prescribe what data types you have*."
>
> You said:
>
> > That I know. That does not answer my question.
>
> So it is clear that you DO know that there is nothing in RM that would
> require a DBMS to implement length constraints on attributes, yet you
> continue to deny that you know it.

I know that there is nothing in the RM, the theory, that would require
lengths. I don't know if there is something about _implementing_ the
RM that would come close to requiring or at least really encourage such
constraints.

> Your question seems to boil down to: why *can* you constraint the
> length of strings in a SQL DBMS but you *can't* in an MV DBMS?

Nope. I understand why you cannot do so within the MV DBMS -- the
schema are not prescriptive, but descriptive. Many "vocabulary items"
(dictionary items, attribute metadata) may describe the very same data,
for example.

Similarly, I understand why you can constrain the max length in a SQL
DBMS. What I don't know is whether you could have an implementation of
the RM (or close approximation thereof) where providing a max length
was optional and not the norm, without some significant penalty.

> It seems a bit like asking "why does car X offer climate control while
> car Y doesn't? What is it about car X that makes it /need/ climate
> control while car Y doesn't".

Not really. I'm only interested in car RDBMS in this question, using
car MV only so possibly someone could understand how there are other
options if they were not otherwise aware of such (we can all get in a
mindset where we only see that which we know). I'm interested in
whether it is essential, really important, enticing, or just tradition
that the car RDBMS designers always seem to (first asking if I am
correct in my observation) have a particular feature.

> Your serif / sans-serif analogy doesn't make sense either. SQL DBMSs
> don't impose length constraints on columns "by default". In each and
> every case the constraint is specified by the person creating the
> table.

Yes, it is the feature of "expecting" the developer to do this that is
of interest to me.

> If it did impose them by default then presumably columns would
> tend to all have the same length constraint, e.g. 50, whereas a cursory
> glance at a typical database shows lots of different length constraints
> being used.

We might eventually have a similar language on this. I think I am
starting to understand you and hope we are getting somewhere in the
other direction too. --dawn

[dawn]

Erwin wrote:
> "logical variaibility"
>
> Dawn,
>
> No matter how you toss or turn it, if you design/define a database you
> *WILL HAVE TO* answer the "range" question for each and every
> individual attribute in your database.

This is surely not the case. If relations (sets/functions) were
defined to a DBMS with max lengths on an item in that set, and the DBMS
does not "think in terms of attributes" (perhaps because it uses
attribute schema information as descriptive, rather than prescriptive)
then there would be no need (or even ability) to constrain the max
length of each individual attribute.

> Is 50 ft a possible length for
> a human person to have ?

No, so I would want to constrain the length of a human to less than 8
feet or whatever. I would feel no need to additionally, or
alternatively, limit the size of the attribute.

> Is 800 pounds a possible weight for a person

No, so if I put a max of 600 on the weight of a human, would you feel a
need to also put a max of 3 digits in such a number?

> ? Is a first name consisting of 1234 tokens a possible first name for
> a person ?

For this one, I would prefer to not to constrain, but to notify of
exceptional name lengths, but I do understand people putting such a
constraint on as it makes some thing easier (while possibly upsetting
some customers).

> Is a 26-character string a possible zip code in a foreign
> address ?
>
> At the logical level, which you claim your question is about, string
> lengths are just a specific appearance of the more general "What's the
> domain of valid values" question.

If you limit a number to 600, you have modeled the conceptual aspect,
not some physical representation to 3 digits. --dawn

[dawn]

David Cressey wrote:
> "dawn" <dawnwo...@gmail.com> wrote in message
> news:1148773922.2...@j55g2000cwa.googlegroups.com...
> > [OK, here is my next "stupid question" as I cut a path in my study of
> > the RM. Those teachers who just want to tell this student how ignorant
> > she is are welcome to sit this out as I really am hoping to
> > understand.]
> >
> > In SQL-DBMS's, like VSAM (and other indexed sequential files before
> > them) a lot of attributes are specified with max length constraints.
> > While there are some attributes where this constraint is related to a
> > conceptual constraint (from the analysis phase), these lengths are
> > often introduced for the logical model or implemenation in the DBMS.
>
> Is VSAM really a DBMS? I looked up VSAM in wikipedia, and the definition I
> found suggests that VSAM is NOT a DBMS, although both IMS and DB2 are
> layered upon it.

I agree that VSAM is not a DBMS. I did not intend to imply they would
be categorized as one.

> In the world of DEC, which I know better, both Rdb/VMS and VAX DBMS were
> layered on KODA. KODA was not a DBMS but a useful building block.

Yes.

> Is VSAM really bound to SQL as an interface language?

Most certainly not.

> I'd like to nail this down before I deal with the original question.

HTH. --dawn

[Bob Badour]

Marshall wrote:
> Bob Badour wrote:
>
>>Alfredo Novoa wrote:
>>
>>>Keith wrote:
>>>
>>>>The performance advantages of size constraints is
>>>>fundamental.
>>>
>>>Only with lazy implementations.
>>
>>Alfredo, the performance advantages of size constraints are fundamental
>>regardless--as are the performance disadvantages.
>
> It seems to me that the integrity-enforcement value of a max
> length well exceeds the performance value.

Indeed. However, this thread originated when one of the
self-aggrandizing ignorants asked a loaded question positing an
attribute with no logical maximum length and presupposing that all RDBMS
products force one to specify a non-existent constraint for physical
reasons.

While the presupposition is false, I assumed we were still talking about
attributes without such an integrity constraint.

In practice, such unconstrained attributes are extremely rare. A
paragraph type for a document would have no logical maximum.

> The performance value doesn't seem so great to me. The one
> circumstance in which it would seem more than trivial would be
> where the dbms could store a varchar inline with the rest of
> the fields, vs. in a separate heap. (But I know virtually nothing
> about database internals, so I could be way off.) That seems
> like it would be a significant win.

The performance value isn't all that great. Neither is the incremental
cost of implementation for the DBMS vendor.

Dawn is just an idiot who is trying to manufacture some semblance
controversy to make herself look more important than she really is.

[snip]

> Another, unrelated point that hasn't been mentioned so far
> (although I might have missed it; thread fatigue setting in...)
> is that in fact, a variety of non-mandatory performance tuning
> options is an indicator of technical *maturity* of a product, and
> we might well ask why another product or family of products
> *didn't* have such.

The issue of physical independence has been brought up. Part of the
self-aggrandizing ignorant's fallacy was to deny a feature for physical
independence that in fact already exists thereby denying the maturity.

[Keith H Duggar]

Bob Badour wrote :
> Keith H Duggar wrote :

> > DW wrote :
> > > 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 ... 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.
>
> Ahhh... the coup de grace! Now, the self-aggrandizing
> ignorant claims the high-ground by dismissing you as too
> stupid to understand her question. A question that you
> clearly understood on its face.

Yeah ... reading that statement of hers really was a tipping
point for me.

> She counted on you to give her the benefit of any doubt no
> matter how small, which you did, to manipulate you to her
> own ends. Finally, she repaid you by implying you are
> stupid.
>
> In the end, was she worth the effort you put into her?

No it doesn't seem that it was. You are right. I apologize
to cdt for helping to propagate so much noise. I was being
too naive. I was thinking "hey maybe if an outsider who just
came along, carefully points out her argumentation problems
she might change." Stupid, I know that now. Can't teach an
old bitch (female dog) new tricks I guess.

The saddest thing is that not only have I wasted time in
recent past, I have wasted future time! Because I have
helped DW add another dozen or so posts to the google
archives. And it is this shear volume of VI postings that
gives them their lasting influence and impedes efficient
learning of future readers. New paths added to the VI maze,
new mud added to their quagmire.

Shame on me. I'm sorry cdt.

-- Keith --

PS. Maybe one day google will create a curated version of
the archives trimming VI threads. A kind of retroactive
moderation. That would be useful.

[dawn]

It certainly did not seem that you try to comprehend even my questions.

What I failed to realize back then and have learned since that time is
that many people in this forum equated "database.theory" with
"relational.database.theory" so even after reading a lot of posts from
the list, I thought there were OO, XML, and possibly IMS, MUMPS, etc
perspectives in a discussion on database theory.

In other words, I did not know this forum was one where one could be a
heretic, I thought it was one where you could discuss database theory.
I soon realized that some segment on cdt formed a religious
strong-hold. That seemed wrong, or at least very unfortunate, but I
tried to change my writing style to accomodate to some extent. I asked
at some point if that was the intent of what the list -- was it
supposed to be comp.relational.database.theory with no room for other
discussions. Enough people agreed that this was not just for the RM
that I decided I really cold put forth my opinions and questions and be
challenged. So, I recognize that I overestimated the logical, academic
nature of the group up front, so I stepped on the toes of those who
thought this to be more of a crdt ng. I have no problem with people
disagreeing and arguing with me, and don't mind being challenged. But
I don't like walking on eggshells with every question I have either,
prefering to be able to state my opinions to get a dialog going.

> And to this day her posts still exude arrogance and

More so than yours? I had never before cdt been told I was an arrogant
person (nor stupid, for that matter), although how does one know? I
don't think my ego is out of line and suspect in any independent
evaluation it would be in the bottom third of those who speak up on
this list, but my writing style might need work. The extreme religious
zeal from some in this forum was a surprise to me and I suspect I
didn't step in on the right foot to be permitted by some people to even
ask questions, much less voice opinions.

> sophistry. And even when a basic logical fallacy is pointed
> out with a clear precise example:
>
> KHD wrote :
> > DW wrote :
> > > 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?

You do understand I was trying to ask you what you meant, right?

> > What the? Where are you getting this "must have", "no
> > choice", "requires", "significantly" crap from? Nobody has
> > said that. You are putting words into my mouth and creating
> > a false dichotomy (yet another logical fallacy). 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.
> >
> > KHD wrote :
> > > 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 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?
>
> she fails to recognize the fallacy, fails to recognize that
> putting words in another's mouth is rude, and instead blames
> it on my "understanding" and "resonance".

You are right that I don't see the logical fallacy. I will admit that
my writing could have been clearer, however.

> DW wrote:
> > 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 ... 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.
>
> And, to cap it off, see later pushes the responsibility on ME
> to "adjust" HER statements:

No, I am asking that you try to understand my question. Are you
willing to give it a try? If so, what question do you think I am
asking in my OP in this thread, given all of the added explanations I
have tried to give? --dawn

[Keith H Duggar]

Alvin Ryder wrote:

[snip a (for me THE) great initial answer]

Wow, I wish I had read Alvin's initial answer before I got
inolved in that damn VI tussle. I would have referred the OP
to parts of your answer several times by now. Much more
concise than anything I said.

Thank you Alvin!

The fact that the OP did not respond to (indeed has
basically completely ignored) this post with the equivalent
of "Gee thanks! That completely answers my question. Now I
can move along with life" is, it seems, conclusive proof
that (as BB has warned many times) the OP is a VI troll with
a BIG rusty troll axe to grind.

-- Keith --

[David Cressey]

"dawn" <dawnwo...@gmail.com> wrote in message

news:1148926992....@g10g2000cwb.googlegroups.com...

>
> David Cressey wrote:
> > "dawn" <dawnwo...@gmail.com> wrote in message
> > news:1148773922.2...@j55g2000cwa.googlegroups.com...
> > > [OK, here is my next "stupid question" as I cut a path in my study of
> > > the RM. Those teachers who just want to tell this student how
ignorant
> > > she is are welcome to sit this out as I really am hoping to
> > > understand.]
> > >
> > > In SQL-DBMS's, like VSAM (and other indexed sequential files before
> > > them) a lot of attributes are specified with max length constraints.
> > > While there are some attributes where this constraint is related to a
> > > conceptual constraint (from the analysis phase), these lengths are
> > > often introduced for the logical model or implemenation in the DBMS.
> >
> > Is VSAM really a DBMS? I looked up VSAM in wikipedia, and the
definition I
> > found suggests that VSAM is NOT a DBMS, although both IMS and DB2 are
> > layered upon it.
>
> I agree that VSAM is not a DBMS. I did not intend to imply they would
> be categorized as one.

OK. I didn't pick up on the comma before the word "like" in your original
post. I thought you were giving VSAM as an example.

Now that we've got that nailed down, on to the next issue: The consensus
of the responders (including me) is that there is nothing inherent in the RM
that would force declaration of a max length for character strings.
There's nothing inherent in SQL either, afaik. There are plenty of systems
that have nothing to do with RM or SQL that impose character limits on
strings.

COBOL is one you should be familiar with.

There are plenty of systems that have nothing to do with MV that permit
manipulation of variable length strings, without an explicint max declared.
BASIC is one you should be familiar with.

With regard to implementation internals, how deep do you want to go?

With regard to increased marketability of products that work with fixed
length strings, that's a whole different matter. And it's where RM theory,
and the design choices made by DBMS egineers start to diverge. We could
have a separate discussion about that.

[dawn]

Yes. I'm trusting that, even though I don't yet know the full answer.

> There's nothing inherent in SQL either, afaik.

Good.

> There are plenty of systems
> that have nothing to do with RM or SQL that impose character limits on
> strings.

Yes, that is definitely the case (I gave the example of card decks).

> COBOL is one you should be familiar with.

We were once intimate, yes ;-)

> There are plenty of systems that have nothing to do with MV that permit
> manipulation of variable length strings,

Absolutely. Java for example.

> without an explicint max declared.
> BASIC is one you should be familiar with.

Yes (a variation thereof is the primary update language and 3GL for MV
btw)

> With regard to implementation internals, how deep do you want to go?

Only deep enough to know what, if anything, encourages those who
develop DBMS implementations based on the RM (however flawed...) to
encourage those using the tool to put in such max length constraints,
if it is the case that they do encourage such. My experience to date
has been that such are required (except for things like blogs and clobs
which are not the way one would implement a lastName, for example).

> With regard to increased marketability of products that work with fixed
> length strings, that's a whole different matter.

Agreed. It is a question about the requirements of the RM as
implemented in DBMS's, not about relative merit nor marketability of
anything.

> And it's where RM theory,
> and the design choices made by DBMS egineers start to diverge.

I don't think that I have seen anything suggesting that if the max
length constraint is an added feature, the RM would be in conflict with
such a decision. The RM is typing-agnostic, including length
designations, IIRC.

> We could
> have a separate discussion about that.

But there still might be something in the requirements for an
implementation of the RM that prompts a design that encourages
developers to specify max length constraints. That is what I'm trying
to figure out. Thanks for sticking to the topic. --dawn

[dawn]

Alvin Ryder wrote:
> dawn wrote:
> >
> > Is there something about the RM that would prompt all (or most?)
> > existing implementations (however flawed) to drive developers to add in
> > these constraints for performance, space saving, or other reasons? I
> > realize there can be variable length attributes, but specifying a max
> > field length still seems to be the norm (is that still the case?)
> >
>
> Hi dawn,
>
> There is nothing in the RM that prompts these constraints, it mandates
> only the existence of the boolean type, all other types are user (dbms)
> definable.

Helpful, thanks.

> The constraints are related to performance, disk space management,
> developer time, the languages used and computing in general.

Again, helpful. Sorry I took a while to get down to this response.

> > As many of you know, I work with database management systems that treat
> > all data as variable in length, while one might specify a length for
> > display purposes.
> >
>
> Are you sure all the data is variable? Or is it limited to something
> large like 2^32 (4Gb) which *appears* to be unlimited but in fact
> isn't?

Yes, you are correct that within the system there is a limit. In the
logical/implementation data model the data are of variable length (but
could conceivably hit some limit, requiring a change to the logical
model)

> Can attributes exceed the resident RAM size? Can they exceed the
> disk size? I seriously doubt it.

They cannot, you are correct. The developer does nothing with that at
the logical level except to ensure that a single attribute would be
defined such that its value would not logically exceed such a limit.

> At any rate most RDBMs have CLOB types which provide something similar.
> CLOB's aren't used as frequently as VARCHARs because they are much less
> efficient. Again that has nothing to do with the RM but with computing
> in general.
>
> > 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, if there is such.
>
> Outputs and fonts are not database concerns at all so that isn't the
> reason.

Good.

> Imagine a 32 bit integer versus an arbitrary precision number which has
> any number of bits! The former only requires 32 bits but the latter
> needs a way to represent the size and then you must represent the
> variable length data itself. Which is easier? Which is faster?

This would depend on your implementation strategy, I would think, but I
understand the point.

> The fixed length data might waste some bits but up to it's limit
> everything is cut, dry and efficient. The variable length data is more
> complex, slower and it isn't infinite after all.

My understanding is that the MV databases have, in the past, been much
faster than their counterparts that define individual attributes to the
DBMS. This might not still be the case, but I would think there could
be models for variable-lengths (data where individual attributes have
no max length constraints specified) that are very efficient.

> The same holds true or strings. And in turn the same holds for records
> made up of such attributes. Furthermore once you store records on disk
> what happens when they outgrow their current location?

My concerns were about the individual attributes having a
specification. I realize that there must be some "chunks" that are
sized and tuned.

> > 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?
> >
>
> Yes you can write any system with variable length data but *no* you
> cannot do it without cost. All of this has nothing to do with the RM,
> we could be talking about word processors, databases or games. You just
> can't have your cake and eat it too.

I might have to ask something like this on cdp to get a perspective
from someone who knows MV implementations, but my guess is that with
their architecture as it is, that platform would suffer more if there
were max length constraints. So, again, I'm thinking there is
something about the RM, though not unique to it (even if just a
statement that attributes must be defined to it, clearly not unique to
the RM) that encourages a strategy of implementation that would be
well-served with limits specified on the attributes, where other models
might have no such advantages. Did that make sense? --dawn

[Frank Hamersley]

Tony D wrote:
> Dawn wrote :
>
>> If I know it, I don't know that I know it.
>
> Eventually, the penny will drop.

No it won't - there have been plenty of opportunities in the past and it
has never happened - cyanoacrylate perhaps!

Cheers, Frank.