Re: Why all the max length constraints?

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? Received on Sun May 28 2006 - 13:27:35 CEST