I am building a web application that has users and orders. I have a question about how to handle the relationship between the two.
An order belongs to a user. But here's the twist, a user can optionally choose to outsource an order to another user.
When an order is outsourced, the original user still remains the owner and only he can modify certain things like price, quantity etc on the order.
The user the order is outsourced to can view some of the order information and can update specific properties on the order like marking as fulfilled.
An outsourced order should show up on both users "orders index".
All the users are "equal" meaning on certain orders a user might be the owner and on others he might be fulfilling the order. A user can also fulfill his own orders.
It doesn't seem like a true many to many relationship as one of the users doesn't really own the order, he just has limited access to it.
What would be the simplest way to handle this order/users relationships? I would like to avoid using a complete permission system, is there a way to simply handle this with an "outsourced" table? How about having a user_id and outsourced_to field on the order table?
Thanks for your input!
If it's of any help, the application uses Laravel.
It seems like your Orders table has two separate relationships with the Users table.
Orders have an owns/owned-by relationship to Users.
Users(1) -- owns -- (*)Orders
One User can own many Orders. One Order is owned by only one User
Then there is a completely separate outsourced-to relationship between Orders and Users.
Orders(*) -- outsourced-to -- (1)Users
(Here I assume that an Order can only be outsourced to one other User. A User may have many Orders outsourced to them.)
The best way to represent this is to have the Orders table have a 'owner' foreign key column into the Users table and another 'outsourced_to' foreign key column also to the Users table.
What columns of Orders the outsourced user can edit will be controlled by the code and not by the dB.
A separate outsourced table will be needed only if Orders can be outsourced to multiple Users at the same time.
How about having a user_id and outsourced_to field on the order table?
Sounds good.
Also, think about a kind of de-normalization, like moving fields, which editable by "outsorced-to" user to separate table.
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')
Scenario:
I have the task to add a new field on a form, which is called account number. When a user clicks submit, it goes and submit the appropriate data to the appropriate tables...not important.
Currently, the tables that are involved are 3: customers, orders, and accounts.
The tables structures are:
Customers -> customer_id (PK), ...
Orders -> order_id (PK), customer_id (FK), ...
Accounts -> order_id (PK), account_number, ...
As you can see, a customer can have many orders, and each orders can have only one account.
Even though in the table structure I added PK and FK, the database engine is actually MyISAM, which doesn't support transactions and relationships. To add "relationship" between tables, the previous developer(s) decided to add the appropriate PK and FK to "fake" the relationships between tables.
PLEASE NOTE: I did not have any part of creating the database and tables; it was given to me as is.
The business logic is that a customer can have only one account.
As far as I know, the way the tables are mapped out, a customer has more than one account.
Without redesigning the tables, it looks like that I don't have a choice.
This is what I have in mind without redesigning the tables:
Create a SQL script to clean up and update account numbers in accounts, so that each account will have the same account number for a particular customer...even though a customer has many oders.
Anywhere in the web app that can insert an account number, I have to check to see if the customer has an account number. If so, then come back with a message stating that the customer already has an account number...maybe select the account number or update it with a new one. If not, then insert it.
Any better options?
By the way, I'm using MySQL and PHP/CodeIgniter.
i have three tables to store details of different types of uses: customers, suppliers, staff
here are the structures of them,
customer(id,f_name,....)
supplier(id, name, address....)
employee(id, name, job_title....)
now i need those to log-in to the system , the log-in details stored in separate table,
user(user_id, password, role, ref_id)
how i planed to work this is, when registering some one, firstly insert the record to customer, supplier or employee according to the person, then insert a record in to the USER table in which the "ref_id" is the id of the previous table. the user is provided the "user_id" which can not be changed and they can change their password themselves.
when log-in, check the user_id, password combination, if ok then takes the ref_id and type, the appropriate table can be determined by the type which may be customer, supplier or employee....
the reason i done this in above way is,
customer, supplier and employee table has many different attributes except few like id, name...so can not maintain all the data in one table. in this situation if we use ids of customer, supplier and employee..would provide duplicate ids because they are separate tables!
so i need to know,
Is it correct the way i have implemented the authentication ?
if it isn't what is the correct way? (please mentioned that the details of the three parties should be handled separately)
i need to define relationship between supplier, customer, employee --> with user table. so is it ok to define three relationship as follows or another solution, how if the user table keep alone without relationship? is it violate the relational database concept?
customer (id-pk) ---->user (ref_id-fk)
supplier (id-pk) ---->user (ref_id-fk)
employee (id-pk) ---->user (ref_id-fk)
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 currently working on a system that would allow users to add additional custom fields for the contacts that they add.
I wondered what is the best and most efficient approach to add such ability?
Right now what I was thinking was to have 1 table per users (with foreign keys to a "main" contacts table) and then adding a column for each custom fields that the user adds (since I don't expect to have more then 100-200 users per database shards [sharding is easy since every users never see each-other's content in this system]), although I am not 100% sure that this would be the right solution for such problems.
Maybe you could try to have one separated table to store a reference to the user, plus the field name and value, this way you will be able to have lots of custom fields.
If you go with Boyce-Codd, you separate the information and store them into a table.
Means one table for all users with a foreign key.
One table per user would lead to hundreds or more tables with possible repeated information.
You need to have one table named USERS that stores the id of a user and fixed info you might want. Then, you could have a CONTACT table, that stores the type of contact user might create, and one matching table USER_CONTACT that matches the user unique id with the id of the contact that was created.
With this, you could have advanced data mining on all the information stored, like nowing how many contacts each user created, who created more, etc...