|
Home > Archive > SQL Anywhere Feedback > November 2005 > Size of unloaded blobs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Size of unloaded blobs
|
|
| Justin Willey 2005-11-08, 9:24 am |
| With the increasing use of RDMS for storing binary data, the inefficiency of
the ASA unload format for binary data is becoming an issue.
Each byte of binary data ends up as something like \x0A in the dat file, so
it ends up a fair bit larger than it was in the database. This starts to
cause difficulties when unloading databases where the bulk of the data is
binary as the unload files can be more than twice the size of the original
database, rather than smaller which they would be otherwise.
Sure a more efficient format could be devised that would do away with the
need to the \x markers and express the binary data as base64 or similar?
Justin Willey
| |
| John Smirnios 2005-11-08, 9:24 am |
| By default, UNLOAD TABLE has the HEXADECIMAL ON option set so binary
columns should unload as
"0x12345678ABCD".
Did you turn that option off or is the column you are unloading actually
a varchar?
It's a growth factor of slightly more than two. Is that still too much?
It's a bit error prone to put binary data straight into an ASCII file.
You could also try turning ESCAPES off but then you'd need to make sure
that your binary data doesn't contain any quotation marks or, if quotes
are off, column delimiters.
-john.
--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering
Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer
Justin Willey wrote:
> With the increasing use of RDMS for storing binary data, the inefficiency of
> the ASA unload format for binary data is becoming an issue.
>
> Each byte of binary data ends up as something like \x0A in the dat file, so
> it ends up a fair bit larger than it was in the database. This starts to
> cause difficulties when unloading databases where the bulk of the data is
> binary as the unload files can be more than twice the size of the original
> database, rather than smaller which they would be otherwise.
>
> Sure a more efficient format could be devised that would do away with the
> need to the \x markers and express the binary data as base64 or similar?
>
> Justin Willey
>
>
|
|
|
|
|