On Tue, 2005-02-22 at 14:30, Heather Johnson wrote: > One of the tables contains personally identifiable information (PII) > (e.g., email, first and last name, etc.). The other contains "click > stream" data (information about where on our website users have gone). > In order to be sensitive to users privacy, we don't want to ever (even > accidentally) run queries that would combine PII and click stream data. > So we're looking for ways to put "walls" up against combining the data. > We understand that anyone with ample access to the database can > deliberately combine the data if they chose to do so in blatent > violation of our policies. But we want to set something up that would > put an obstacle or two in the path of anyone who might accidentally run > such a query. > > The ideas about setting up views might work. I guess we'd just have to > change the permissions of users who have access to the db so that they > can only use the views and not query the tables directly. Why not change the keys that currently connect them to something different (i.e. random noise) and make a NEW table that could join them with those random keys that is restriced access wise to only the chosen few. Or do you need to actually ever re-reference the two datasets? If not, then just lose the connecting data when you insert the rows. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
