Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Whats more efficient?

Re: Whats more efficient?

From: McEvoy <>
Date: 02 Apr 2001 09:27:38 -0500
Message-ID: <>

In article <> Heinz Huber <> writes:

   Tom wrote:
> >
> > While this would be a good place for multiple tables, you could also
> > bit-map the permissions. Something like the file permissions in Unix.
> > i.e.: Area1 = 1, Area2 = 2, Area3 = 4, Area4 = 8......
> > Access to Area1 & Area2 would be 3, access to Area2 & Area3 would be 6,
> > and so on. This would be a "challenging" method, as you need to truely
> > understand the bit-map, but it is efficient.
> >
> I like the Idea and see how its much more efficient. Could you recommend a
> way to include a level of access in addition to Y/N. An example would be
> that 'a user has write permission in area 3'. Also - would you be able to
> direct me to any additional information available reguarding this method?

   As soon as you put more than boolean information per area, I'd not    recommend using a bit map for this. I'd suggest you go with your multi    table design and add a column access_level. Otherwise, this will get    very ugly to maintain. And also keep in mind that the number of areas    (perhaps multiplied by access levels) is restricted by the size of the    type used for the access map.

   IMHO, bit maps are only good for mapping (at least more or less)    unrelated boolean (Y/N) information.

   I don't think you should not have a problem concerning performance when    you use the multi table approach in a decent RDMBS with appropriate keys    (and indexes) defined.


I would have to agree. The bit-maps are only good for boolean flags. If the only information is can this user access a certain area, it would be good. The moment you introduce additional information for each area, you need to go to a table.


Micheal Mc Evoy   
Tools Developer,
RS/6000 Engineering Software, IBM Server Group
Austin, Texas
Received on Mon Apr 02 2001 - 09:27:38 CDT

Original text of this message