Hi Stephane, I of course simplified the problem a bit. However, the bitmaps are actually artificial entities which I'm building up from some underlying tables and some clever indexing schemes. The problem is, I don't have total data model control, and the permissions and storage info are stored in two different tables. Through some clever indexing and views, I'm presenting two different bitmap views. The idea is I can do a unique lookup on storage, a unique lookup on permissions, and then AND them together and provide a resultant bitmap, availability. The front-end app will then use that availability bitmap to decide what options to present to the end-user. The problem is the heterogeneous nature of the two bitmaps.
Finally, I'm fully utilizing the bitspace I have, because the 2 bits for permission represent two different (and independent) pieces of info. In the example you provide below, there is no way to express P1 AND P2 with storage. In other words, my permissions matrix looks like: 00 - No permissions 01 - Permission for user to acquire doc via email 10 - Permission for user to acquire doc via on-line viewing 11 - Permission for user to acquire doc via email or on-line Note that the bitmap is full, and storage has not entered into the picture yet. So, Storage will say either 0, not stored or 1, stored. I need to AND the permissions and the storage. But, I need to AND the single bit storage with two bits of permissions. Does that make more sense? -Mark -----Original Message----- From: Stephane Faroult [mailto:[EMAIL PROTECTED] Sent: Tue 1/6/2004 5:13 AM To: Multiple recipients of list ORACLE-L Cc: Subject: RE: Mark, This is what spontaneously comes to my mind and may not make a lot of sense in your case, but why do you need TWO bitmaps in the first place? Your second (Permission) bitmap uses 2 bits to store three states (no permission/P1/P2). This is enough to hold the STORAGE information as well, eg 00 Not stored 01 Stored with no permission 10 Stored with P1 11 Stored with P2 I of course assume, and may be wrong on this account, that storage is a pre-requisite for permission. Otherwise I would use 24 bits. I presume that your bitmaps don't appear as such, and therefore whether you have one or two fields is pretty irrelevant to the end-user. It looks to me easier to understand and maintain that some Rubik-cube-like bit-twiddling. HTH, SF >----- ------- Original Message ------- ----- >From: "Bobak, Mark" <[EMAIL PROTECTED]> >To: Multiple recipients of list ORACLE-L ><[EMAIL PROTECTED]> >Sent: Tue, 06 Jan 2004 01:39:25 > >Hi, > >Well, since I can't sleep, I may as well try >solving a problem. > >This is a bit odd, and I'm trying to think of the >most efficient way to do >it. I've set up some bitmaps in my app. Consider >we have documents that >we want to sell. In order to be able to sell a >given doc, we need to have it >stored in the vault and we also need to have >negotiated the proper contract >w/ the publisher. So, I've got two bitmaps, >STORAGE and PERMISSIONS. > >But, here's the hook. There are 8 different types >of storage, so I have >an 8 bit mask. However, for every storage type, >there are two types of >permission. So, I have a 16 bit permissions mask. > >What I'd like to do is take my 8-bit STORAGE mask, >say it's 10110011 >and convert it to 1100111100001111. Note that all >I did there was take >each bit in the input mask, and make the same value >repeat. So, 0 would >become 00, 1 would become 11, 10 would become 1100. > Does that make sense? >Once I've done that, I can take my STORAGE mask >that's now stretched to 16 >bits, and directly AND it with my PERMISSIONS mask. > > >So, my question is: Is there a nice, scalable way >to take my 8 bits and >expand them into 16 bits, in the way that I'm >describing? A clever bit >twiddling expression would be perfect, but anything >that's efficient and >scalable will do. (The end product will be hidden >behind a view or stored >procedure.) > >Any thoughts, anyone? > >Thanks in advance, > >-Mark -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Bobak, Mark INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
