Markus Ostenried wrote:

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

This is a question near and dear to my heart. Fixed length fields made
all the sense in the world when we were dealing with punched cards, but
honestly, that was a while back.

All civilized languages as well as many uncivilized languages have
either builtin or layered string types unbounded in length. Really, who
is to say what the longest legitimate last name should be. Yet
databases continue to a specific "variable length" type with a specified
upper bound? Why?

Databases should support a type "string" of unspecified length.
Simple? Absolutely.

There is one reason not to, however. And that is pig-headedness and
slavish devotion to machines with a 64K address space.

I have completely given up on the idea of fixed types in Falcon (not
that the MySQL DDL languages lets you at the feature, of course).
Records are stored in an encoded record format where each field is
encoded by actual value, not declaration. The encoding, by actually
measurement, is about a third less than the length of a Firebird record
after run length encoding, about even less after expansion. The actual
encoding, incidentally, evolved here on the architecture list.

With this encoding, it is completely practical to support an arbitrary
"string" type. If somebody wants to put a length constraint on a field,
that's ok (even if primitive). Civilized APIs like JDBC, however, will
never see a limit or restriction.

Come, guys, strings don't really need a declared max length. Unless you
want to emulate punched cards.