Re: [GENERAL] How to Prevent Certain Kinds of Joins? - Mailing list pgsql-admin

From Scott Marlowe
Subject Re: [GENERAL] How to Prevent Certain Kinds of Joins?
Date
Msg-id 1109105459.30529.119.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: [GENERAL] How to Prevent Certain Kinds of Joins?  (Heather Johnson <hjohnson@nypost.com>)
Responses Re: [GENERAL] How to Prevent Certain Kinds of Joins?
List pgsql-admin
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.

pgsql-admin by date:

Previous
From: Heather Johnson
Date:
Subject: Re: [GENERAL] How to Prevent Certain Kinds of Joins?
Next
From: Bruno Wolff III
Date:
Subject: Re: Upgrading 7.3 -> 7.4.5