tim@sybase.com (Tim Wood) (02/28/90)
In article <771@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: >tim@ohday.sybase.com (Tim Wood) writes: >>One can index BLOBs ... by maintaining an identifier column value >>of a simple datatype for each row containing a BLOB. The indexing >>on the simple datatype is bound to be faster and more reliable than >>the one-off indexing code a user writes for his/her BLOB datatype. >I can show counterexamples (they happen to be textual datatypes). >So it's not "bound to be". Might be on average. What it's bound to >be is more subvertible, less safe, less productive. ... I'm interested in the counterexamples. I question the efficiency and robustness of directly indexing several-MB images/documents in the DBMS with user-written code. I don't understand the connection between your points on integrity and productivity, except that less robust code leads to more bugs, hence lower integrity and productivity. >>Moreover, one can change the "ordering" of the BLOBs by changing >>the identifier values, whereas with directly-indexed BLOBs one would need >>to change the type-specific indexing algorithm. This amounts to changing >>part of the datatype (or object type) definition. >Sounds like a bad idea to me. I prefer object ordering to be defined >by the object. E.g. you mind if I change ordering of ints? Say by one >application without other applications' knowledge? In making my point I was assuming that the object definition (in particular, indexing order) might be subject to change. For identifier columns, integrity rules could be defined to prevent changing the BLOB ordering, although a strong binding between the BLOB and the i.d. columns would be missing. The points you are making about integrity are valid. I'm still learning about this topic, but I don't have a clear sense of the need or practicality of full access methods support on abstract data types. -TW --- Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.