Database design issue - visibility of content - mysql

Question

I'm having some trouble determining what kind of approach should I take designing this database and I cant figure it.
The app will show some items to the user if he's given access to see them. Different users different access (possible to have access to the same item)
When user is logged in. First he will be presented with list of items that he has access to see.
Then he clicks on one item and goes to a list of versions of that item that he has access to see (not necessarily all of them)
Then he clicks on the version of item and he is presented with list of subversions of that version that he has access to see
So, different users, different access restrictions and admin can make changes on who sees what versions, subversions and items
Items
+*Item1*
-*ItemN*
*-Version1*
-*Subversion1*
Picture1
Picture2...
+*ItemN+1*
My question is how to design tables for this kind of database (how many, how to connect them etc)
Thank you

Answer 1

You will need to have multiple tables. I see the structure like this:
TABLE 1 ITEMS
each version and sub-version of an item is considered an item.
+---------+--------------+--------------+--------
| ITEM_ID | DESCRIPTION | DATA_FIELD_2 | etc ...
+---------+--------------+--------------+--------
| .. | .. | . | ...
TABLE 2 ITEMS_TREE
this table contains all the relations between items (and versions)
+---------+--------------+--------------+----------+
| TREE_ID | FATHER_ID | SELF | ORDER |
+---------+--------------+--------------+----------+
| .. | .. | . | ... |
where FATHER_ID and SELF are foreign keys connected to ITEM_ID Primary and unique key.
FATHER_ID will be NULL for root nodes (items),
SELF will refer to the node itself (item or whatever).
A version will have FATHER_ID that is the ITEM_ID of the item and so on for how many levels you want.
You will need a table of users and a table of permissions in which you can add the single item a user will be able to see, for example:
+---------------+---------+---------+
| PERMISSION_ID | USER_ID | ITEM_ID |
+---------------+---------+---------+
| ... | .. | .. |
That will contain a row for each permission. If you want to have group of people seeing the same collection of items the you can use group and have a different way to handle permissions, avoiding too much record in the database.
An example can be using a GROUP_ID instead of USER_ID, you are inserting some kind of item in the visible list of that group.
I hope this can be useful to you, let me know what you think about it

Answer 2

create table items
( -- endless self-join hierarchy
itemId int auto_increment primary key,
parent int not null, -- 0 if no parent, avoid nulls
itemName varchar(200) not null, -- "Our Wedding (My 2nd, your 1st)"
pathToFile varchar(200) null -- "/users/all/jpg/miama.jpg"
);
create table users
( userId int auto_increment primary key,
fullname varchar(100) not null
);
create table items_users_rights_junction
( id int auto_increment primary key,
itemId int not null,
userId int not null,
rightsMask int not null, -- here is your Visibility
-- FK's to enforce referential integrity:
CONSTRAINT fk_rights_items
FOREIGN KEY (itemId)
REFERENCES items(itemId),
CONSTRAINT fk_rights_users
FOREIGN KEY (userId)
REFERENCES users(userId),
unique key (itemId,userId), -- no dupes on combo
key (userId,itemId) -- go the other way, benefits by covered index
);
Subversioning is baked in (naturally) to the items hierarchy. Populate and query at will. Self-join knowledge would be helpful.
To make it a very useful covered index on (user_id,itemId,rightsMask) that would never need to go to data page for rights. Rather all is in the index with left-most being userId. This covering index could still be considered thin.
A covering index refers to the case when all columns selected are
covered by an index, in that case InnoDB (not MyISAM) will never read
the data in the table, but only use the data in the index,
significantly speeding up the select.
Some sample data for the first two tables:
insert users (fullName) values ('Kim Jones'),('Harry Smith');
truncate table items; -- will be run a few times to get demo data right
insert items (parent,itemName,pathToFile) values (0,'Our Wedding',null); -- id #1 top level no parent
insert items (parent,itemName,pathToFile) values (1,'Our Wedding - Cake pictures',null); #2 place holder
insert items (parent,itemName,pathToFile) values (1,'DJ spins the tunes',null); -- #3 place holder
insert items (parent,itemName,pathToFile) values (2,'She smears cake','/users/all/jpg/miama.jpg'); -- #4
insert items (parent,itemName,pathToFile) values (2,'He feeds the bride','/users/all/jpg/cake123.jpg'); -- #5
insert items (parent,itemName,pathToFile) values (5,'He feeds the bride take 2','/users/all/jpg/cake123-2.jpg'); -- #6
insert items (parent,itemName,pathToFile) values (5,'He feeds the bride take 3','/users/all/jpg/cake123-3.jpg'); -- #7