baudchaser

[quote author=448191 link=topic=123697.msg513247#msg513247 date=1169741445] Ouch. Mulitple ACL's require multiple ARO lists.. Say I have 2000 users and 100 AXOs (articles - sections - whatever), that would result in 200000 rows in the ARO table.  What a pain... [/quote] Yes!  This is what I was describing, only not exacly in ACL/ARO terms.  If I have 2000 users and 100 "groups" (marketing group, IT group, a group for a "contracts" page - basically defined as any "section" of the Intranet that needs to have its permissions handled separately) then I would end up with 20000 records if the average person ended up needing at least read access to at least 10 of those groups. [quote author=448191 link=topic=123697.msg513247#msg513247 date=1169741445] Alternatively I could change table 'acl' to hold serialized arrays with only the difference between the specific ACLs... [/quote] Not sure what you mean by serialized arrays, but in my first post I was trying to resolve the monster table "problem" by using a comma separated string to store values that would otherwise end up as separate records.  To extract the data, I'd be parsing the comma strings into an array and checking perms for each group against that array - in effect, I was transferring database load to CPU/code load.

I'm still here and reading - so much going through my mind right now (and that I've been testing) that I haven't been able to take the time to reply to each of your suggestions - don't think I don't appreciate the suggestions.  :) Bitwise has allowed me to cut down from 10 fields (read, add, modify, delete, etc.) into one field for perms, which is cool.  ACL I'm still researching and trying to figure out. I think 448191 and I are thinking along the same lines - even with the concepts mentioned here, I'm ending up with at least one large table.  If I only needed to assign permissions once per user accross the entire site - this would be easy!  But I need to be able to manage the permissions for each "group" of pages, which means an additional record in the table for each group! I have some number of permissions (read, add, modify, delete, grant, etc being cumulatively stored as a single hex number), which I need to be able to assign to a page (actually a group of pages since I'm grouping up similar pages using parentid's).  I also need to specify which user (or group of users) needs access to that group of pages. Let's say I want to grant a user read access to both IT and HR groups.  It would require 2 entries in the linking table, one for each department.  The more groups I want to give a user access to, the more entries there are for that one user.  This is my fundamental problem - or maybe it's not a problem and just the way it is... groupid = all pages in a certain group, 1=IT, 2=HR, etc.. userid  groupid  perms 1        1          0x00000001 1        2          0x00000001

[quote author=effigy link=topic=123697.msg511626#msg511626 date=1169580733] Have you considered using bits to handle the permissions? See [url=http://www.phpfreaks.com/forums/index.php/topic,113143.0.html]this[/url] topic. [/quote] Ahh...I was not aware that PHP had built-in capability for binary/hex like this.  Very enlightening read, thanks! But I think I may still be struggling a bit with the implementation.  This would allow me to cut the number of fields down from 1 per permission type (I had 7 fields - read, upload, create, modify, delete..etc) to having just one field containing the binary/hex string. But how would I link the perms to certain pages, but not others?  For example, I might want a user to be able to upload, but only to certain pages.  I imagine the only way I could do this would be to have a table where each user had a record for each groupid they have access to Just making up the hex for permissions here, but: userid  groupid  hex 1        1          0x00000001 1        2          0x00000003 1        3          0x00000006 1        4          0x00000001 1        5          0x00000001 2        2          0x00000001 2        7          0x00000004 .... Is this right, or am I missing something?  This goes back to my initial concern - the permissions table growing to a rather unwieldy size quickly as the number of users and groups increases.  Let me give a real world example.  We might have 50 unique "groups" that need their own specific permissions.  We hire an executive who wants read access to all, and additional access to some.  Would that necessitate 50 records for that one new exec???

I am designing a company intranet, have two working prototypes for the permissions structure, and am wondering which one is more efficient (or more accurately, if one or the other is just going to be too slow). Method 1: There is a basic users table with userid as the primary key.  Webpages are each assigned a groupid, which is essentially the permissions group to which it belongs.  For instance, each department will have its own groupid, and every subpage in that department typically has the same groupid. I also have a "perms" table with userid as the primary key, and read, write, delete, etc. as fields.  Each of these fields consists of a comma separated string containing the groupids to which that user has permission. For example: IT has a groupid of 1, and HR has a groupid of 2.  If I want userid 1 to have read access to both, the "read" field in the perms table has the string "1,2". When the user logs in, I explode the comma separated string for each permission type (read, write, modify, delete, etc.) into an array, and store as a session variable.  When that user tries to access a webpage, I use the "in_array" function to determine if that page's groupid exists in the session variable. Method 2: I have the same users table, and the same groupids.  But the permissions table has one record for each user for each groupid they have access to. For example: Userid needs read access to both IT (groupid = 1) and HR (groupid = 2), but write access only to IT.  The permissions table will look like this: userid    group    read    write ----------------------------- 1          1          1        1 1          2          1        0 Method 1 seems to emphasize using the code to do most of the work, where Method 2 seems to emphasize using the database to do most of the work.  I guess my dilemma is that I do not know whether the code in method 1 is outperforming the bigger query in method 2.  I imagine as the number of users/groupids increases, the table size will increase exponentially in method 2.  Is method 2 preferrable at smaller table sizes and method 1 preferrable at larger sizes?  When will CPU utilization become the bottleneck? I guess it is possible that both methods are equally viable given a reasonable number of records (2000 users, 50 groups) and also possible that I am approaching this at the completely wrong angle.  Thoughts?