woodsmailbox wrote:

>> What are you doing that requires records over 64K?
>>
>
> 64k says nothing about its consequences. I can barely use 4k utf8
> strings (non-indexable that is). Whenever I get another "sort record
> too big" or I put too many in view columns or sp params, I drop the
> bar at 2k, and go on with life. Don't like it though, so I rant aloud
> :)
>
> So it's not really the storage limitation that bothers me, but the
> limitations of various runtime structures, like in list(), group-by or
> view columns, which pop up at unexpected times, and you have to
> rethink your queries again.
>
>

Please tell use what you are trying to do. Most people find that
normalized databases don't come close to bumping into restrictions
(you'll find the 64K record limit very, very common among databases).

Blobs exist for two reasons. One is that some data items have no upper
bound whatsoever. A Word document, for example, can be arbitrarily
long. The other is that fetching large objects is expensive, and if
large fields are not required for a statement, not fetching them is a
huge win.

In 1983, it made sense to make blobs separate types. In 2009, it makes
more sense to bifurcate at runtime based on a length threshold, but
blobs and non-blobs sharing common semantics.

That said, I think the problem may be in the way you are designing your
application. Tell us about it. Maybe we can make some suggestions...