I am currently designing a database for a file sharing service. Every folder that is created on this service will have its own Table(Folder_) each Folder will also be added to a Table which will have the folders and their owners.
Is this bad practice? The reason being I have there are several features which I want to incorporate into this service which require me to have a table for each folder i.e permissions/different levels of access.
e.g The owner of Folder A has added 3 users with different levels of access to the folder User1, User2, User3.
User1 has view only access.
User2 has edit access.
User3 has full access.
The reason I can't see another of doing it except for creating a table for each folder is, if I had a Table of File/Folders with the usual attributes where could I put the users who have access to the folder and their level of permission? Also how would User1 view what folders they have access to with a big search of the entire database etc
The reason I dont think it can be good practice, is the amount of tables that will be in the database?
I would suggest a single table for folders, another table for users and a third table for user folder permissions. If you are making many tables that all have the same columns, you are probably not normalizing correctly.
Table: Folders
FolderId
FolderName
OwnerUserId -- references Users table to identify the owner
(additional columns as necessary to describe a single folder)
Table: Users
UserId
UserName
(additional columns as necessary to describe a single user)
Table: FolderUsers
FolderId -- references Folders table
UserId -- references Users table
Permission -- (ViewOnly, Edit, Full, etc)
The FolderUsers table is called a junction table, it allows a many-to-many relationship between Folders and Users, just add a row for each folder/user combination.
Related
I am working on developing an insurance app. We have designed a database table containing all user profile related information, as well as their approvals to different privacy policies.
My question is - which would be a better option to keep track of the history of all changes in the information described above?
Archive table or Audit Log table? or are both needed?
Details
Archive table - a copy of the current table will be created but will contain all the past data. All present data will be in the current table.
Audit Log table - generic table that contain columns that describe which tables and columns from those tables changed and to what values.
Is having one enough? or is it a standard practice to have both an archive table and an audit table to keep track of historical data of user profile related information?
Tried doing some research but all I could find was the archiving of the actual audit log data, not the archiving of the actual data. Makes it seem more confusing.
We are running single database for rest app server. We have three types of users
for customer
for administrator, and
for partners
Currently they have different tables and username and password are also in separate respectively Now We need to refactor this schema as user are expanding.
So should a single table User with Role table is OK ? (Here Role can be admin, partner or customer, manager).
OR
Should we a keep as it is as We will be having issue if we use User and Role table:
if an admin acquire a username then that username can not be the same again for customer or partner due to unique constraint.
I think user role can not be as "Customer" as customer is not a Role. Role can be admin, manager etc
I think this is not the right way to keep in single table. What are your suggestions?
I think you should create three tables for your user management, considering the fact that one user can have several roles (ex:- admin can also be a manager Or Customer can also be a partner). So User table and Role table have a Many-To-Many relationship. In order to create this relationship, you have to create 3rd table having userId and roleId as composite primary key.
additionally, i noticed that you are going to save user's passwords in the database. For the security reasons do not store passwords in plain-text. Instaed store the hash of the password using one way hashing algorithm.
You can read more about it from here -> Best way to store password in database
Yes, it would be better to keep separate tables because of the following reasons:
1. As you specified, Customer is not a role.
2. Since administrators would be limited in number, there is no point in fetching the record for authentication/authorisation from a large data set having the customers. It will hinder the performance.
User
id
userId
role (foreign key)
etc..
Role
id
name
etc
the above structure is best practice.
if you really need extra fields for admin, partner or customer
you can create separate entity for each one and you can refer user as a foreign key like as follows
Customer
id
name
user(foreign key)
etc
My database has been created with table names looking like this for the user information:
DROP TABLE [dbo].[webpages_Membership];
DROP TABLE [dbo].[webpages_OAuthMembership];
DROP TABLE [dbo].[webpages_Roles];
DROP TABLE [dbo].[webpages_UsersInRoles];
Is this somewhat of a standard when it comes to table naming conventions? If I now want
to make some new tables would it be reasonable to also name them things like
admin_application
admin_account
or do DBAs normally assign tables used to hold different things to different users when they want to group table types?
I would just like to find out how people normally group tables in an application. Am I
right to assume they are all under one owner in this case dbo or do people leave the
table names alone and have them stored in different owner accounts?
Yes, the best way is to use schemas to divide logically grouped tables. Good example of this is Adventure works database you can download from CodePlex. They have several schemas for different parts of the company such as Person, Production, Purcahsing, Sales and other. See more details on how MS designed this DB.
Have a look at schemas:
create schema webpages authorization dbo;
GO
create table webpages.Membership (...
create table webpages.OAuthMembership (...
create schema admin authorization dbo;
GO
create table admin.application (...
It used to be that before SQL Server 2005, you needed to create a database user in order to create a schema. However, since then, you can create schemas for organizational purposes. Schemas cannot contain schemas, so it's a single level. Schemas can contain any database object, i.e. tables, stored procedures, etc..
Schemas need to have an owner, hence the authorization bit above. Specifying dbo here will make it the same as if you had created it in the dbo schema.
i am trying to design an ER diagram or model of a dvd rental system but i am having problems with the design i have so far i want to put an entity for an administrator so that he can see everything and i also want to modify the customer entity so that the customer can only see what what is in the shop and not everything ,the customer can only check the basics
here is my ER MODEL below
All users have to have privileges to access the database. The Privileges are dependant on the user.The basic privileges are.
SELECT | gives the right to read the table contents.
INSERT | gives the right to add new rows to the table.
DELETE | gives the right to remove rows from the table.
UPDATE | gives the right to update the contents of the table.
The customer will have SELECT maybe UPDATE to any table required for his part of the application.
The application administrator can have all the privileges above to all the tables in the application database.
The database administrator will have all the privileges in the database and will GRANT privileges to customer & application administrator
This is a very simplified version and you should research further, especially the database being used
I am in database design development phase. Application will work with large number of users (LARGE :))
I designed 80% of database but I have one Users table which is connected to everything else:
Users {UserId, FirstName, LastName, Username, Password, PasswordQuestion, PasswordAnswer, Gender, RoleId, LastLoginDate etc etc}
I saw asp.net membership database structure where Users and Membership are two tables. My questions are:
Should I use one users table with all users data in it or more tables?
If answer is 'more tables', what tables to use? Any advice on how to structure relation between those tables?
This is sample relation that I have, and trying to improve. I don't understand why user and userChild are separated tables?
How many tables you need depends on your modeling needs.
For example if you include the RoleId in the Users table then you'll only be able to assign one role per user. Is that what you want?
Otherwise, if you have a separate table linking users to roles, you'll be able to assign more than one role per user.