Markus Ostenried wrote:

> Hi all,
>
> first of all let me say that I know about features more pressing and
> needed, like SMP support, merging of architectures etc. I'm with all
> the sensible people on this subject :)
>
> A feature I would like to see for a very long time - in fact since I
> started using Delphi 2 and InterBase - is a character data type of
> variable length. I don't think of Varchar(n) here because it limits
> you to n characters.
>
> IMO it makes sense to be able to limit the length of a character
> column but I'd rather do it with a constraint. The reason is
> constraints can easily be changed, e.g. to loosen a size restriction.
> I personally don't see any sense in restricting a last name to let's
> say 60 characters. This is an arbitrary boundary that everyone in the
> SQL world uses because it's enforced by the available data types. It
> isn't necessarily based on the shape of data that one wants to store.
>
> Another problem I encountered is with changing the maximum length. If
> I encounter that some clients use computer names longer than my
> assumed maximum of 15 characters then I have to change not only the
> one table I use to store the computer names. I also have to change
> every field that may get to contain this value through concatenation
> to ensure all the fields are big enough to hold the now longer values.
> (I know that's not a normalized structure in this special case). You
> also have to adjust all variables in stored procs and triggers that
> reference a Varchar(n) column that has been made bigger. This may get
> better with usage of domains in stored procs and triggers. But with
> usage of variable length strings there would be no change necessary to
> that variables.
>
> I think the current behavior is just an artifact that is quite
> annoying in modern times. I don't see any performance benefits from
> using Varchar(n) because the engine would still know about the maximum
> length because of a constraint you can specify. Also internally run
> length compression is used so I don't think the record layout would
> change that much.
>
> I don't know the engine internals but I fear changing everything to
> use variable strings would be quite a big task.
>
> I read some of Jim's slides about netfrastructure and falcon, and I
> have to say that I really like the idea of having variable length
> strings. To the outside and for compatibility everything looks the
> same if you specify a length constraint - which the new implementation
> of Varchar(n) would do internally. SQL standards aren't violated. But
> if you want to then you can simply omit the length constraint and code
> happily ever on.
>
> I just wanted to bring this wonderful step into the present of
> programming languages to your attention :) And I'm asking for your
> opinions on this matter.
>
> Please bear in mind that I'm a student not yet finished doing computer
> science and that English isn't my native language. So if I didn't make
> myself clear enough feel free to ask me what I'm really meaning.
>
> Regards,
> Markus
>

Hi Markus,

I am not a core developer, but I would say what I think about it.

1.) This is good idea
2.) This is will bring problems

I think a more relaxed approach is good, I have more than once to
enlarge some column because what I thought that would be enough prove to
not be so. But there are things that will complicate. for example:

When I design my reports I define the width of a "column" to hold the
size of the "maximum" field size, so the field don't wrap in multiples
lines ( I think that a single line listing is far more pleasant to read
than a multi-line one besides that if every row has one of the dozens
fields wrapped, the listing size will at least double the size).

There are a lot of places where the data from my system go to other
systems, and I already have problems with it, I tend to define the
fields with sufficient space to hold the data, and in the majority of
the cases when I would export data to other systems my column
definitions are bigger than the other system, so what's my option ?
Truncate the field.

Truncate the field is not a good option, since the lost part of the
string could hold important data, but If I have a field constraint to
lets say 40 chars, the user will abbreviate the data to fit on 40 chars
and have a good meaning If I just leave it open the user could put 80
chars, and when I truncate that information I could potentially lost
important information. Let's rephrase it, I prefer that the user make
the information fit on 40 chars than to cut out the excess when it's needed.

I agree that disk space is not a question anymore, but what other
implications we will have if we let a user to supply an unlimited amount
of data on every field ?

How does the BLOB's fail to hold the "really" big strings ?

How would unlimited strings be indexed ? How could a developer knows if
it will outfit the maximum index size ? (of course the index length
could be removed, but at what cost ?)

The user interface will be ugly (in my opnion) if you could not predict
the size of the field, potentially data will be hidden (yes I know the
user could scroll trough an Editbox but is this ergonomic ?), I dislike
the idea of a window with one Editbox per "line" with 1024 pixels of
width :-)

The first time I read Jim's proposal I think it will be excelent, than
after thinking for a while some "problems" (in my point of view) begun
to pop-up.

But to have the option is better than have no option :-). I for one
would use limited size strings in the majority of the places, and in
some places use unlimited strings (for potential variable fields or non
critical fields), but I think that if I really needed it I had used
BLOB's far more than for "Comments", "Observations", "Notes" fields.

just my 2 cents.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br