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
