I have a php/mysql application. There are users who have folders. Folders can only be one level deep. Each folder can have unlimited number of documents. The relevant tables are as follows:
user_table:
user_id(PK), name, password, etc
folder_table:
folder_id(PK), name, user_id(FK into user_table)
document_table
document_id(PK), user_id(FK), folder_id(FK), date, name, etc
All queries to operate on folders and documents are of the form
select/update/insert <blah, blah, bhah>
where user_id = %d
Now, I'm looking to allow users to share they folders with other users. I want to do this in the least disruptive way possible. I also want to minimize run time overheads of resulting WHERE clause.
I've been wracking my brains and googling but haven't found a simple enough solution. I can think of implementing it in a manner similar to unix's (read, write, execute) along with (owner, group, others) mechanism. But it seems a bit too complicated for my humble system.
I would really appreciate if someone could give me pointers as to which approach I could possibly take. My goals are simple:
The system doesn't require a whole lot of reworking
At a minimum users should be able to share folders with other users or groups (I
will add concept of groups if needed)
There should not be too much overhead in SQL statement's WHERE
clause as opposed to what it is now (as simple as: WHERE
user_id = %d)
Sharing folder(s) with user(s)
You can to add a table *folder_user* with columns folder_id(FK), user_id (FK)
The user_id in *folder_table* represents the owner of the folder. When the owner shares this folder with another user, you add folder_id and user_id (with whom folder is shared) into folder_user table.
Later, you can add column access (enum 'READ', 'READ_WRITE') to the same table, to see if a user is allowed to edit documents in the folder or not.
Sharing folder(s) with group(s)
You need a table group
Then you need to add users to groups, so add a table *user_group* : user_id(FK), group_id(FK)
Then, to give access to of a folder to a group add table *folder_group*: folder_id(FK), group_id(FK) to give access for a folder to a group.
Related
I'm looking to create a database for users with multi-level user rights and I don't know how to go about doing this. What I mean is that I want a manager of a business to be able to purchase my product; that person would be given Owner rights, but would also be able to grand additional users under that license--those people would be given Manager or User rights. Each level (as well as my level: Admin, and my staff: SuperUser) would obviously have individual rights/privileges).
What I'm asking, more specifically, is how to set up the database. For example, if my business is a corporate calendar/organizer, the Owner would set up departments, each with a Manager and many Users. What's the best and most efficient way to structure the database? Like, would each user (and each calendar entry) have to be associated with an ID that belongs to that specific Owner account? I'm just a little lost as to what the best way to organize the database to keep everything together, as I will have multiple different Owners with their own company structure under them.
I want to use MySQL and PHP.
I tried to make this as logical as possible. I think I'm making it too hard, but I am sure there is a standard that makes it easier....Thanks in advance.
At the very least every product/object whatsoever needs a foreign_key in its table, as for example the user's id. This is necessary and sets the relation from the product/object with the user.
And then it depends on how complex you want your system to become. An easy way would be to just use boolean columns in the user table, like an admin, an editor column and so on, with only true and false as values. In your code you could then use if and case to check if a user is an admin and show him parts of your app or not. Like a delete link for example. But you could also restrict updating and deleting to people whose user has a true value in the sufficient column.
The more complex route would include other id-fields in the tables which set a relation of something to something else. Like say you want the user to be a seller or a buyer, then you would add seller_id and buyer_id columns to the products table and check if the ids correspond with the user_id. But not "the" user_id, but a different user_id which you saved when the user created the product listing for example. This way you could guarantee, that besides your staff the user who created this thing has rights to edit it, too, because of the product's user_id being the same as his user_id (current user) when he is logged in to your system.
You could do even more complex relations but then you'd have to create another table and save other ids in it which relate certain users with say other users. In this table you save let's say a maintainer_id and a maintained_id, both have values of certain user_ids but this way you could make a relation between objects one user could change, though they belong to others. Or if you're talking of customers so the mainter_id would be allowed to write messages to those people with maintained_id, like if someone is a seller and the others are potential buyers.
I'm having a little trouble understanding exactly what you're looking for. From what I've gathered, it seems you want a database that holds permissions, users, and departments. In this very basic example I've created 3 tables. (assuming one user can only belong to one department)
You could set a foreign key in the users table which links to the primary key in the permissions table. The departments table would have the foreign key of the user_id.
You could base all of the logic on what each permission can do with your queries and application side logic.
(I can't embed images due to not having 'enough rep')
I've done quit a bit of programming with php/mysql on small scale personal projects. However I'm working on my first commercial app that is going to allow customers or businesses to log in and perform CRUD operations. I feel like a total noob asking this question but I have never had to do this before and cannot find any relevant information on the net.
Basically, I've created this app and have a role based system set up on my data base. The problem that I'm running into is how to separate and fetch data for the relevant businesses or groups.
I can't, for example, set my queries up like this: get all records from example table where user id = user id, because that will only return data for that user and not all of the other users that are related to that business. I need a way to get all records that where created by users of a particular business.
I'm thinking that maybe the business should have an id and I should form my queries like this: get all records from example where business id = business id. But I'm not even sure if that's a good approach.
Is there a best practice or a convention for this sort data storing/fetching and grouping?
Note:Security is a huge issue here because I'm storing legal data.
Also, I'm using the latest version of laravel 4 if that's any relevance.
I would like to hear peoples thoughts on this that have encountered this sort problem before and how they designed there database and queries to only get and store data related to that particular business.
Edit: I like to read and learn but cannot find any useful information on this topic - maybe I'm not using the correct search terms. So If you know of any good links pertaining to this topic, please post them too.
If I understand correctly, a business is defined within your system as a "group of users", and your whole system references data belonging to users as opposed to data belonging to a business. You are looking to reference data that belongs to all users who belong to a particular business. In this case, the best and most extensible way to do this would be to create two more tables to contain businesses and business-user relations.
For example, consider you have the following tables:
business => Defines a business entity
id (primary)
name
Entry: id=4, name=CompanyCorp
user => Defines each user in the system
id (primary)
name
Entry: id=1, name=Geoff
Entry: id=2, name=Jane
business_user => Links a user to a particular business
user_id (primary)
business_id (primary)
Entry: user_id=1, business_id=4
Entry: user_id=2, business_id=4
Basically, the business_user table defines relationships. For example, Geoff is related to CompanyCorp, so a row exists in the table that matches their id's together. This is called a relational database model, and is an important concept to understand in the world of database development. You can even allow a user to belong to multiple different companies.
To find all the names of users and their company's name, where their company's id = 4...
SELECT `user`.`name` as `username`, `business`.`name` as `businessname` FROM `business_user` LEFT JOIN `user` ON (`user`.`id` = `business_user`.`user_id`) LEFT JOIN `business` ON (`business`.`id` = `business_user`.`business_id`) WHERE `business_user`.`business_id` = 4;
Results would be:
username businessname
-> Geoff CompanyCorp
-> Jane CompanyCorp
I hope this helps!
===============================================================
Addendum regarding "cases" per your response in the comments.
You could create a new table for cases and then reference both business and user ids on separate columns in there, as the case would belong to both a user and a business, if that's all the functionality that you need.
Suppose though, exploring the idea of relational databases further, that you wanted multiple users to be assigned to a case, but you wanted one user to be elected as the "group leader", you could approach the problem as follows:
Create a table "case" to store the cases
Create a table "user_case" to store case-user relationships, just like in the business_user table.
Define the user_case table as follows:
user_case => Defines a user -> case relationship
user_id (primary)
case_id (primary)
role
Entry: user_id=1, case_id=1, role="leader"
Entry: user_id=2, case_id=1, role="subordinate"
You could even go further and define a table with definitions on what roles users can assume. Then, you might even change the user_case table to use a role_id instead which joins data from yet another role table.
It may sound like an ever-deepening schema of very small tables, but note that we've added an extra column to the user_case relational table. The bigger your application grows, the more your tables will grow laterally with more columns. Trust me, you do eventually stop adding new tables just for the sake of defining relations.
To give a brief example of how flexible this can be, with a role table, you could figure out all the roles that a given user (where user_id = 6) has by using a relatively short query like:
SELECT `role`.`name` FROM `role` RIGHT JOIN `user_case` ON (`user_case`.`role_id` = `role`.`id`) WHERE `user_case`.`user_id` = 6;
If you need more examples, please feel free to keep commenting.
I am working on a social networking website in which I have idea of creating groups, events and friend list. I want user privacy for his friends like as given below :
1. User can select friends who can view his personal info or who can't.
2. User can manage who can see his events and groups and who can't.
I have designed a table structure for the same that I am pasting below :
User_location_id
User_id
Allow_friends(ids separated by comma)
Deny_friends(ids separated by comma)
Allow_groups(ids separated by comma)
Deny_groups(ids separated by comma)
Allow_search
(Chapters of State,City)
Friends
(Visible to Some, Hide from Some) ( if 0 then I am geeting friends ids from allow_friends else Deny_friends)
Groups (Visible to Some, Hide from Some) ( if 0 then I am geeting friends ids from allow_groups else Deny_groups)
Privacy_for_type
Privacy_for_name
Should there be any other structure that will be efficient and can minimize database hits and don't make database intensive.
If you're going to design database tables, you might want to read about normalization:
http://en.wikipedia.org/wiki/Database_normalization
Storing ids separated by commas makes it difficult to update those records and to prevent duplicates. I'd recommend your allow and deny columns be split into separate related tables. This will not make it any more database intensive as you'll still only need one query, it just means you might have to have a query with a join.
I'd recommend using two (or three) tables, separating users + groups, and permissions.
The users/groups table can contain information specific (and isolated) to the user/group (so #'s 1 and 2 for the user) and then you can add a field for "type" or "category" that says if it is a user or group. If the information you're storing for users and groups are different enough, you can just have separate tables for each.
The permissions table can contain any permissions, including #'s 4-9 on your list (I don't really know the context of 10/11.) The table can also be use to manage group membership. The following is an example of how you could structure the permissions table:
permid: arbitrary unique primary key auto_increm column
asset_cat: the category (or table name) to which the asset belongs
asset_id: the userid, groupid, etc. for which the permission describes
uid: The user who is seeking permission
permission: the permission being sought for the asset_id by the uid
value: the value of that permission
Some example entries:
//Same as listing 1338 in user 1337's Allow_Friends Field
1002, 'user', '1337', '1338', 'Allow_Friends', 'True'
//Lists 1337 as a member in group # 43
1003, 'group', '43', '1337', 'Member', 'True'
These are just some examples to help you get started. Let me know if this was helpful, or if you need me to clarify anything :)
I have a simple document management system which currently offers "public" access to documents based on a company id - I would like to implement access controls on a user by user basis. I am happy with how to check access rights etc in PHP but not sure how best to maintain approved users in the table in an efficient way.
A document could have public access or private access restricted to x users and as I don't know the value of x it doesn't make sense to implement multiple fields in MySql called user1, user2 etc.
There is a table already called users and one called documents. Would a new table called users to docs make sense or is there a better way to implement this so I can check if a user is entitled to access the document if they attempt to?
Best method is to have link tables, e.g.
table #1: users (id, ...)
table #2: documents (id, ....)
and
table #3: user_documents (user_id, document_id)
where user_id and document_id are foreign keys pointing at the users and documents tables
If a record exists in user_documents, then the user has access to the document. If you need to implement various levels of access (read/write/etc..) you'd store that in the user_documents table as well in extra fields.
By comparison, if you had something like
table #1: users (id, doc1, doc2, doc3, etc...)
where the doc# fields point at documents this user has access to, you'd have to have N fields in the table to handle permissions for N documents. If only a few users have rights on N docs and most have far fewer, you'd be wasting a lot of space on unused fields. And there will always be some joker who requires N+1 documents, meaning you're modifying your tables every time.
With the link table, you only have 2 fields, ever, and only as many records as there are user/document access pairs.
I've got a PHP/HTML/Javascript driven front-end for a MySQL database which archives different files/papers for our office (kind of an electronic index for physical paperwork).
The users want to be able to have permissions on each of these entries; for instance HR complaints need to be indexed, but should not be viewable by all users of the database.
The user heirarchy is two-tier. Each user is a member of one OR MORE distribution lists (similar to an Email list). When a file is indexed, the user choses the permissions for others: for instance he/she can select the following for a sample HR complaint:
List | Permission
`````````````````````````````````
HR Dept | Read/Write
Board Members | Read
John Smith | Read/Write
Mary Smith | Read
and should be invisible to anybody else. Now I've tried several things to implement this, the most recent being a relations table which relates the following:
User 1->Many DistributionList // Assoc the user to some lists
Permission 1->Many DistributionList //Indicates level of permission that the list has
Permission 1->Many User //Indicates level of permission for each user
However the permission table contains a row for each file for each permission, which, given a few thousand files and ~50-60 lists/users, means a few hundred thousand entries. Since this index will not be flushed often (maybe flush files older than 50 years) that number could skyrocket. Not to mention that the queries are somewhat complicated, and take a decent amount of time (~1 second for the SQL request) for only a couple hundred files.
Is there a more efficient way to create this sort of User based stuff? Is it possible instead to make users in SQL itself with these permissions and let the connection handle these things?
tl;dr: What is the best way to put read/write/invisible permissions on entries in MySQL using PHP, Javascript, HTML and PHPMyAdmin?
If there are not many groups (64 max) you could use a SET of permissions for each file (1 extra column).
http://dev.mysql.com/doc/refman/5.0/en/set.html
So each file could have one column denoting which groups it belongs to, which can be expanded as the systems grows.
You could also add a second column if you want to go beyond 64, but that would require more complex queries (keeping departments separate would help here, HRgroups, Boardgroups etc..)
You could also add exceptions to specific users or create another group. But as you say one associating entry per file/user is the best your going to get.