Scott Marlowe wrote:
> On Tue, 22 Jul 2003, Shridhar Daithankar wrote:
> > On 21 Jul 2003 at 22:35, Jochem van Dieten wrote:
> > > Shridhar Daithankar wrote:
> > > > e.g. Virtual private database? What is that? Unless I know
> > > > what to expect out of that functionality, how can anybody
> > > > offer an opinion or material on that?
> > > >
> > > > A link explaining what is virtual private database would be
> > > > great there. Like
> > > > <http://www.oracle-base.com/Articles/8i/VirtualPrivateDatabases(VPD).asp>.
> > >
> > > *That* is called a Virtual Private Database? It is just a fancy
> > > way to do row level security on a single table in the database.
> > > That article should be called "How to fake an updateable view
> > > with check option.".
> >
> > Well, no matter how you and me thinks this is not very relevant or
> > of any practical use, tons of people use it/will use it because
> > oracle offers it to them.
> >
> > Sigh... there are quite a lot of things that are not
> > ideal. Definition of ideal is one of them..:-)
>
> Reading that page, it looks to me as if VPD are just schema sections
> with security applied. I.e. Postgresql can do that.
In the CRS realm, this is known as "multihosting," where the idea is
that you have One Big Database that supports lots of customers, with
suitable access controls so that they can only access their own data.
Thus, Delta, Lufthansa, Continental, and American Airlines all store
their reservation information in One Gigantic Sabre Multihost
database. Sabre can sell reservations for all of them (it has
"cross-host" access), whereas the individual airlines, when they run
queries, only see their own data.
We've got an "embarrasment of riches" in terms of different ways of
grappling with this:
- Individualized views, where users are given views on tables.
The CRS approach involves there being individualized views, where
users/groups can only look at their share of the data. Of course,
that takes a lot of work to configure things.
- We can also have multiple schemas, where users each have their own
separate sets of tables, and where they might be rolled together via
UNION ALL.
The latter is probably simpler to get right, from a security
standpoint, as the 'default' behaviour, for users to only have access
to tables in their own schemas, isn't nearly as "leaky."
--
output = reverse("ofni.smrytrebil" "@" "enworbbc")
Christopher Browne
