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.