Re: Why all the max length constraints?

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? Received on Sun May 28 2006 - 16:04:10 CEST