Hi, thanks for the comments, > If I'm understanding right - the view contains an additional > column that is an MD5 hash of some or all of the data in the > base table, right?
Close. It's got all of the data in the base table except for the colum that's being hashed - we show the hashed version of that instead. Like a password table, where the base table has the plain text passwords and usernames, and the view only shows the hashed passwords and usernames (though it's not for passwords). > set up second table, with two columns. One is id number to > correspond to id number in original table, second is to hold > Md5 hash. Createn index on the MD5 column for sure, possibly > a two column index. I'm not sure whether it would be better > to create it as (id, md5_col) or (md5_col, id); I'd test it > each way I guess. > > Set up insert/update/delete triggers on the first table to > add/update/delete records in the second table with ID and the > MD5 hash. > > Then re-create your view to show you all the columns from the > first table plus the MD5 column from the second table, > joining on the id column. This sounds good, and this way I don't have to change the first table much at all (as it's a replicated table and my luck with replication only lately seems to have gotten good). What kind of performance hit will I be taking because of the join in the view (e.g. every query to the view is going to have to have to do the join, yes?). Or is this neglegable as long as the hash and pointer of the second table are both indexed... Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
