[thelist] DB field length limits

[Techwatcher]

Hi, Jon -- and thanks for responding. In fact, your response makes it
crystal clear that the DB packages STILL do NOT offer enclosure or
nesting.

When I use APL (or J, or variants), I don't have to set any limit on
file field length (apart from hardware and OS limitations, of course).
I can, therefore, take a sample text file some author sent me (for
instance), and enclose it, and dump it into my nested n-dimensional
array. Later, when I'm retrieving that author's sample text, I would
disclose the whole file. If, for some inane reason, I needed to put the
whole files into an ordinary DB package's field, I could either:
[1] find the maximum length of the field and set up the field length in
    the DB package's to equal that, or
[2] truncate the values of the disclosed "fields" and put those into a
    standard DB field.

Your standard DB package won't be much use to back-end processing for a
writers' site, handling text files -- unless I make the writers type
(retype!) into a textarea or other controlled length thingie. (Ugh!)
But MySQL will do, I think, in our fulfillment process, when handling
simple, predictable things like addresses, names, money, etc. I would
prefer to have this information online when we get to confirming orders
and related processing, so my (probably enormous by then) off-line DB
should be massaged to read into an ordinary MySQL db at that point.

So now I have another question for MySQL persons:

If I decide to rename all the fields in our online form (which I'm
considering because the new FormMail does NOT sort alphabetically and,
although I could do this as part of my processing, it's annoying
(especially in checking for consistency across my forms!):
[1] Are there characters to AVOID, such as underbars or dashes?
[2] Are there rules, such as don't prefix field name with 0 or another
    number?

Thanks a lot! (-8

Carol S.
techwatcher at accesswriters.com

> One of the advantages of this, of course, is that your
> actual data can take up exactly as much room as it needs,
> and no more. You don't have to allocate to all fields the
> length the largest value will need. Does MySQL, SQL, or
> any other DB Package have this feature yet?

Of course they do, and have done for many many years.

CREATE TABLE testTable (testField varchar(23))

You now have a variable-length column, which will take 1 to 23 chars and
store them using only the space necessary.

AIUI there are performance benefits to using fixed-length columns, so
if you
know that all data will be the same length (e.g. MD5 hashes of 32
characters), then it makes sense to use CHAR instead of VARCHAR.

Cheers
Jon