Roy Lyseng wrote:
Jim Starkey wrote:
My thinking about blobs has changed. Blobs originally were an escape
from fixed length SQL types. Now that I've abandoned fixed length
SQL types, the utility of blob as a declared type diminishes to about
nothing. Nimbus will retain clob/blob types to humor the
traditional, but they will (probably) be synonyms for string and
bytes, respectively. There will still be a storage type for blobs,
but it will be dynamic, based on a length threshold. (Why, I can
hear you asking? Simple: There is no point to slop around a
high-res jpeg to update a last_reference column in the same row.)
I guess VARCHAR existed before BLOB/CLOB, so I am not so sure about
that...
Uh, for a little historical context, try this:
http://en.wikipedia.org/wiki/Binary_large_object
To me, CLOB is similar to a VARCHAR but can be significantly longer
and has reduced functionality (Why do you want to sort or join on a
4GB CLOB?) As a database implementor it simplifies my work because I
can operate on the LOB in chunks instead of always materializing the
whole thing. During a complex join the LOBs are merged in only in the
last step when the result set is sent to the client, and the client
may even skip parts of the LOB it has no use for.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
