Re: storing byte values

On Aug 8, 8:06 pm, pascal.dull..._at_veda.net wrote:
> On 8 Aug., 12:28, Frank van Bortel <frank.van.bor..._at_gmail.com> wrote:> Did you take a look at the Migration Workbench?!?
>
> I did today... Nice tool indeed!
> Unfortunately it seems to support only DB2/400 version V4R3 and V4R5.
> We have V5R4. But I tried it with an MS SQL-Server 2005 database which
> has been migrated from the DB2 before.
>
> Anyway, the migration needs to be done from within our application
> with JDBC, but I can use the Migration Workbench for some tests and
> experiments.
>
> As Vladimir pointed out in a previous post, the RAW type does NOT have
> the one-column-per-table restriction. I got confused with LONG RAW. So
> I can use RAW for the key fields and BLOB for larger fields that are
> not used as a key. This means that our migration has a restriction of
> binary keys with maximum 2000 bytes. I think we can live with that for
> some time.

Ha, I seem to have been having problems with lengths yesterday. :) Of course, max RAW length is 2000 bytes, not 4000 as I stated (that's VARCHAR2 limit.) Anyway, I urge you to reconsider your approach of building unique indexes over RAW(2000) - this is going to be very inefficient both storage- and performance-wise. Hashing the data using a cryptographic hash function, like SHA-1, and using a unique index on hash values is much more efficient and doesn't take a lot of effort to implement. Since uniqueness of the data seems to be the only concern, you can hide the hashes from the application by using views and implement hashing in triggers so that the application doesn't need to be changed.

Regards,

   Vladimir M. Zakharychev
   N-Networks, makers of Dynamic PSP(tm)    http://www.dynamicpsp.com Received on Wed Aug 08 2007 - 12:29:14 CDT