I am developing a hospital system where patients can allow user access to their information as per their choice. There are different group of users for e.g doctors, nurses, registration clerks, insurers and managers. A user can access either patient personal details, patient medical details, patient prescription details or all. Each user is identified by a unique "user_id" and each group by a unique "group_id".
A patient can block:
a single user (e.g a nurse)
a group (e.g all nurses)
a group with some exceptions (e.g block all nurses except nurse1 and nurse3)
specific users but allow their respective groups (e.g allow all nurses except nurse1 and nurse3)
Once access is granted to a user or group they will be assigned permissions like read, write and delete.
I'm having a lot of trouble figuring out how to design my table(s) along with their fields so that I can store these access rights information.
At first I would deny to all users and groups as standard. And then the following table structures:
tblPatients
Name, patient_id (I would prefer uuid's), etc.
tblUsers
Name, user_id (I would prefer uuid's), etc.
tblGroups
Name, group_id (I would prefer uuid's), etc.
tblUsersGroups
users_groups_id, user_id, group_id
The user_id references to tblUsers and the group_id to tblGroups.
The idea behind the structure of tblUsers, tblGroups and tblUsersGroups is, that a user can be member of several groups.
Now to the important part, the whitelist:
tblWhitelist
id, patient_id, write_group_id, write_user_id, read_group_id, read_user_id, delete_group_id, delete_user_id
In this table you put the access id's, I would do it each per row and you can have as many rules in there as you like.
For your query you need a username or user_id, get the membership(s) of this user in tblUserGroups and then look at tblWhitelist whether the user or his group is allowed to do the action. The user rights should be have a higher priority.
I think, this way could work,
Related
If a user can have multiple addresses and phone numbers, is it possible to design the database in such a way that I can enforce integrity between data?
For example:
users(id,name)
addresses(id, description, user_id -FK to users)
phones(id, description, user_id -FK to users)
orders(id,address_id -FK addresses,phone_id - FK to phones)
How can I be sure that in the orders table I won't accidentally insert a record with user1 address and user2 phone number?
I'm sorry if this was asked before but I don't know how to search for this situation.
Where is the Orders table? It will have columns user_id, address_id, and phone_id.
For data entry, if a known user calls in an order, then the UI brings up the existing addresses and phones for that user. The order-taker can quickly click on them. Or the user can say to use a different address. Then the UI assists in adding a new address for that user.
I am looking for a schema to give to "fruits" permission by:
User
Group
User and Group simultaneously. I mean "OR" "AND"
The idea is to get the best performace to do that relationship.
The idea is to get the best performace to do that relationship.
Is that the idea? Or is the idea to do it correctly? There are infinitely many fast solutions to incorrect results.
The problem you pose, by the way, is pervasive in security: how to characterize groups for authorization. The groups are hard to define and harder to administer.
If the id for users and groups are taken from the same domain -- that is, no user id is also a a group id -- then you can use the union of user and groups. If groups can also be group members (not you've as shown), you have a recursive definition, which SQL supports. You can then query a recursive view for permission membership. Now all you need is a simple table to reflect them:
create table permissions (
int member_id not null -- user or group,
char permission not null
check permission in ('R', 'W', 'X') -- or whatever
);
If users and groups are in distinct domains, the query is the same, but the view and the permission table both need an additional column to reflect whether it's a user or group.
Hello Stack Overflowers,
I'm redesigning a system for an ordering group.
We have a hundred or so companies (ordering accounts) that order from us.
And maybe 40 of those companies also have online stores (admin accounts) with us.
An online store has a customer list of users that belong to their store, and the admin account lets them create and manage customers and customer orders.
So the customer shops, and when finished the order goes to the company.
The company verifies the order (combines orders to save shipping if they want) and then send it(/part of it) to us or fill it(/part of it) from their inventory.
We pack their order at our warehouse and ship it to the address on the order.
And we invoice the company.
The company then settles payment with their customer. (we never bill a customer directly)
Hopefully that wasn't too convoluted...
So again, we never bill a 'customer' directly. But in our current system, we store all accounts (ordering, admin, AND customers) in the same way.
While considering the redesign, I've questioned if this is the most logical approach. And I was thinking of storing our billable accounts (ordering and admin) in an accounts table and customers in a separate customers table.
The way I was thinking of setting this up was, our accounts have an accountID XXXXX, while users have a similar userID YYYYY, but are identified by a composite key of the two (XXXXX-YYYYY)
So company A's first customer is AAAAA-000001 and company B's BBBBB-00001. This seems fine when I think about things like customer orders being billed to their parent company, and displaying all of a companies customers, etc.
But is it a bad idea to have a customer table where customers non-unique customerIDs, even if that isn't the Primary Key?
I know I could make it work, but is it suboptimal when doing something like a customer_address table that relates a customerID and an addressID? Wouldn't it then need to use an accountID + customerID right?
Originally I was thinking they would all be accounts, and the account number would just be structured that way AAAAA-00000 being the admin account, AAAAA-00001 being customer 1, and so one.
But that brings me back to, should our accounts table treat our clients/billable accounts and their customers the same?
Sorry if this question is kind of all over the place. I think that demonstrates how unsure I am of how it should all be structured...
Any input would be greatly appreciated.
I am building a database for a web application that includes users following each other. What would be a good design? I was thinking this:
TABLE: users ROWS: user_id, name, pass, email, activated, user_level, registration_date
TABLE: relationships ROWS: relation_id, user_id, followed_id
What do you think of that?
For the user table, I guess what you have is correct. If you need to add more columns, you could simply alter that table, or add an additional table with a one to one relationship.
As for the relationships table, I think that is correct. Although i wouldn't call it followed_id. I would suggest that you could use that table for many different types of interactions, so I would call it user_id and interacter_id and the relationship_id would be a number of different types of interactions (follow, poke, etc).
I want to create some kind of 'activity feed'. For example, There are total 1000 users in database, of which there are 100 people in contact list of user X, who is concerned with those 100 users only, and want that if any of them posts a note (in general, takes an action), he wants to get that update on my page. For this purpose, do i need to make a database table, like:
id user_id note_id
In this table, there will be users which are not concerned to user X, so I will make some query like,
select user_id from activity_table which exists in contact list of user X
Is my approach correct regarding this matter (for example database table design and query)?
Is there any better approach?
If I understand you correctly I think you need a relation table where you will store user_ids of the user that is being concerned and of the user that concerns.