[thelist] DB field length limits

Wade Armstrong wade_lists at runstrong.com
Fri May 24 13:13:01 CDT 2002


on 5/24/02 10:46 AM, Techwatcher at techwatcher at accesswriters.com wrote:

> 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.
>
If you wanted to put the binary file, untouched, into the db, most (Oracle,
SQL Server, PostgreSQL, MySQL, Access, etc.) dbs offer fields with BLOB
(Binary Large OBject) datatypes. SQL Server's text datatype, for instance,
offers a max length of 2^32 bytes - I hope none of your authors write that
long! BLOB fields don't need to have their length specifically stated,
because of how they work.

Of course, access to BLOBs is generally slower than to varchar or char
datatypes. That's why a good DBA will take time to understand the data
they're planning to store and develop a schema that's optimized for storage
and retrieval of the expected data.




More information about the thelist mailing list