Re: Why all the max length constraints?

Tony Andrews wrote:
> 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?"

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 Received on Sun May 28 2006 - 15:17:02 CEST