Drizzle's blobs are currently limited to 4 gigs. Raising the
limitation is no big deal.
Cheers,
--Brian
On Nov 16, 2008, at 8:43 AM, Jim Starkey <[EMAIL PROTECTED]> wrote:
Sheeri K. Cabral wrote:
My thought -- this should be left up to the application -- some may
auto-detect, others may want to store a mime/type to hint/force/
coerce how to process them.
Blobs are merely byte strings, and are ordered by the numerical
value of each byte.
If you think of a blob as a "binary large object" you can make the
argument that binary collations apply. However:
1) In MySQL terms, { VARCHAR | TEXT} BINARY uses a binary
collation on a character string, and { VARBINARY | BLOB} is a byte
string. Very different!
2) You have to decide whether to fight Jim's on the existence of
blobs and insistence that "blob" isn't an acronym, or accept the
fact that the ISO 2003 SQL Standard lists both "BLOB" and "BINARY
LARGE OBJECT" as "binary large object string types", thereby
assigning a meaning to "blob" that Jim didn't intend...and doesn't
like.
http://savage.net.au/SQL/sql-2003-2.bnf.html
(SQL 99 also defines it IIRC, but I couldn't find a handy link)
3) You'd have to somehow define at least one collation, and do you
really want to make a character set where "smiley face" comes
before "heart"? There is no such a thing as case (upper, lower)
with regards to blobs either.
In general, I don't see a reason for specifying a collation unless
there's more than one way to sort the data type. (many charsets
have at least 2 collations -- foo and foo_bin).
----------------
What kind of constraints would you have on a { BLOB |
VARBINARY } ? Current MySQL constraints/attributes of binary
strings are:
VARBINARY(length) -- length is from 0 - 65,532 (+2 bytes field
overhead +1 byte for 1 set of 8 nullable fields = max row length of
65,536; length of 0 can hold '' or NULL)
DEFAULT [NULL] - VARBINARY only, not BLOB
NOT NULL - I could be wrong on this one.
BLOB max length = 65,532
Sigh. Originally, "blob" didn't stand for anything. The "binary
large object" came from a marketing type who couldn't handle
whimsy. For an abbreviated version, see http://en.wikipedia.org/wiki/Binary_large_object
.
I have since conceded the differentiation between blobs (binary
gook) and clobs (textual good) to enable reasonable and proper
client side character set translations for clobs (run a jpeg through
a UTF-8 to Cyrillic translation at your own peril, boys and girls).
But yes, blobs were (and are) intended to be without size limit to
store images, documents, marked up documents, and the like in
databases.
If drizzle is to be defined by history rather than requirement, by
all means limit blobs to 64K. People who want to store PDFs, Word
or Open Office documents, html, xml, images, and what not can just
find another database system to use. There are lots of
alternatives, so it won't be much of an imposition.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
