Can a give to a user permisions only for the tables he create? For example, if I add an user, I want he can use the rest of the tables but no delete or modify. Only the tables he create.
It's that imposible?
Best regards!
Related
I'm new to MySQL and databases, and this question is more about best practices than exact code.
If I want to create a database that let's users register an "account" so they are then able to access and track the value of virtual goods in a video game, including selecting items from a list and marking them (thus requiring the choices to be associated with their account), Is it better to store the users choices in the same table that holds their username/account-info? Or should the information be stored in a separate table with a reference to the associated account?
Or should I create a table for each user, instead of having one for registration/account info, and another for data, etc.?
Does the best practice for this vary with the expected number of users and/or amount of data?
Is there a way to set it up that allows for handling growth from 2 or 3 users to hundreds?
The answer is to create one table for accounts, one table with choices that are referenced to that account with some type of token.
There's no reason to create a new table for each user. You should have one table, and differentiate between the users using the data in the table (e.g., the userid, the username, etc).
I have a project which requires me to setup custom privileges, divided in three categories "Admin, Manager, User"
My regular approach is to distribute Privileges in one table as headers, then add a raw for each category with 0 or 1 to activate or deactivate the privilege for a group like follows:
id|name|can_do_this|can_do_that
1|admin|1|1
2|manager|1|0
3|user|0|0
however my professor requested that each privilege to be added separately per user no per group like follows:
id|user_id|privilege|active
1,1,can_do_this,1
2,1,can_do_that,1
3,2,can_do_this,1
4,2,can_do_that,0
my question, for the sake of my sanity.. which is more efficient? his point is that IF we needed to add a new privilege we won't need to ALTER the table to add a new column.
hope this question makes sense.
To me, this is a very simple data modeling issue. You have two "entities" in your data model:
users
privileges
This suggests that each one should have its own table.
Because this is a many-to-many relationship (many users can have a given privilege, one user can have many privileges), a third table is normally used for expressing the relationship; this is often called a "junction table" or "association table".
Your professor gives one very good reason for expressing the values in rows rather than columns: The ability to add new privileges.
I can add a few more:
The userPrivileges table can have a createdOn column so you know when the privilege took effect.
The userPrivileges can have a createdBy column, so you know who granted the privilege.
The userPrivileges table can have a suspended column, so you can temporarily suspend privileges.
I would suggest you the second one, because like that as your teacher says you don't need to Alter the table. Altering the table would mean adding a new 1 or 0 for each member in your table (you could use a default value but you will still need to change the values for those users that need the privilege).
The way your teachers says you could have another table with all the privileges, and use a foreign key.
That way you could add a new privilege and asign it to the users they need it with a default value of "1", and if you need to revoke the privilege change it for a "0". No innecesari rows will be added for default, that in small tables is not a problem but for bigger ones it is.
id |user_id |privilege |active
1 1 can_do_this 1
2 1 can_do_that 1
3 2 can_do_this 1
4 2 can_do_that 0
As per my experience, If you don't want to add the extra column every time whenever a new privilege required to be updated in apps. Then go with second option.
Benefit:
Option-1: There will be no redundant data for group and that can be managed easily as you can apply the unique constraint on the group name and hence it will not requires the insert every time.
Option-2: You don't need to add the alter the table you can simply verify does new permission is already there or not, if not then simply add a new insert or update the existing permission.
Dis-advantage:
Option-1: You need to alter the table every time whenever new permission comes in.
Option-2: Whenever you want to add the new permission for a group first you have to identify that the records already exists or not, then you have to insert into table. And while validating the is also a bit of complex compare to the first option.
So, both has its advantage and disadvantages. If you think from data redundant perspective then go with option-1, else go with option-2.
I would prefer to go with option-1 as per my knowledge, and what I will do I just maintain a extra table which identify the permission and physical column between them, and I will make it generic.
ThatsAll!!!
How can we represent a relation where there is no need to add a foreign key in the table in DBDesigner? For Example, If i have 2 Tables As:
1) Admin
2) Machine
Suppose the relation "Admin can Add machines",
there is no need of Admin table's primary key to go in Machine's table as foreign key. Or you can say that i don't want to add it. But still i want to show this relation in my ERD. How can i do it using DBDesigner?
The best way is to create separate table Permissions.
Then there will be a row with specific permission Add machines
This way you can assign different permissions to different users.
Obviously you will need 2 more tables for this to work: Users where the user data is kept and say user_permissions with 2 fields only user_id & permission_id where you keep the info which user has which permission.
This is the right way to design scalable permissions that can expand and accommodate any set of permissions.
Here is a question from a newbie. I need to store music data(URL, artist ...) for each user. Should I put all data in one single table with distinct keys for each user. Or maybe it is good idea to have separate tables for each user.
I am making an online player.
Thanks in advance
You will create huge database if you are going to create seprate table for each user, make a table structure that will contain entries of all user in single table....
Create a single table with different user privileges for ex create an
group column table and provide different grouids to different users
e.g. groupid =1 for admin ,2 for normal user etc.
A separate table for each user is not appropriate.
You need one table for the music data (URL, artist, ...).
If the only item you store about users is the name, you can put that into the music data table as well without violating database design principles too much.
As soon as you store additional information about users (e.g. password, e-mail address) you need a second table for the user data and connect the music data to the user data via a foreign key in the music data table (or, in case of a n:m relation, a third table).
If you are looking for further information about database design, keywords are functional dependency and normalization.
Enhanced relationship diagrams may help you in designing your database. It might be worth mapping out your proposed database using these diagrams before you implement them.
This is a good tool to make sure you have a correct database design for you and as previously said below deal with functional dependency and normalization.
This is a good website to help you if you haven't done this before: http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html
I am redesigning a database and I need some help.
I have two "User" tables, USER and APPLETCUST, with one being an internal user and the other being a customer.
Since I want them both to login to the same area, I think I need to create a new table that holds login information and whether or not the person is a USER or an APPLETCUST and then have a relationship to the respective USER or APPLETCUST to get that information.
What do you think? Is there a better way?
I'd recommend merging the table, but you already suggested it yourself :-) Creating a third table that references the two tables is also possible but might get messy unless you write the constraints properly.