Hi, El 28/10/10 15:19, Thomas Mueller escribió: > I think comparison of large binary data (BLOBs) should be discussed in > another topic. No problem, but I still talking about binary.
> The new "lob in database" feature does now use a > checksum (hash code), but not a cryptographic one. Great, from this point the expressions of equality on binary/blob data would be ready. Tip. The RSA MD4 Checksum (rsa-md4) used in rsync isn't properly cryptographic, is more a 128-bit checksum that's believed to be collision-proof. Comparing two of this 128bits checksum get 99.9% probability that original binaries are exactly alike, but comparing only a byte[16]. The cryptographic version of RSA MD4 is using DES (rsa-md4des). In Rsync v3.0 MD4 was replaced with MD5 digests. > If the checksum matches, the content is compared (so that equal blocks are > shared). I considered using a cryptographic checksum, but that could be added > later as an option. I agree. An initial version like this should do the job and can be enhanced later if needed. > In most cases it would slow down adding BLOBs too much I believe. Returning to the beginning of this thread, I think there are two very specific use cases in which should focus. First, the case of serialized java objects in binary type fields (not necessarily BLOBs) of typical prudent size (say less than 100 Kb). The other case is that of files in LOBS contained in the database, where isn't prudent to estimate a typical size. The case of serialized java objects we should find an implementation of equality expressions in the database more efficient than de-serializing the objects and compare on application level (as ODBMs does). This case could be the sql/jdbc "|*JAVA_OBJECT <http://download.oracle.com/javase/6/docs/api/java/sql/Types.html#JAVA_OBJECT>*| " data type , if it had different storage requirements than the plain binary data type. For the second case I believe that an affordable equality implementation with 99.9% accuracy is sufficient for the vast majority of cases and would be left to application ensure perfect equality if this was so critical to pay the cost. This use case could be the sql/jdbc BLOB or OTHER or ARRAY<BYTE> data type. Separating these cases in different data types, we make space for implementing a specific equality function (and storage) appropriateto their typical/potential size, which only affects the performance in proportion of the benefit it adds. regards, Dario -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
