I have an e-commerce project that contains there type of user admins,merchants and normall user in merchant section I need to make employees for merchant, like each merchant will have many employees with him and I'm confused between two structures for database first one:
In the same merchants table add another column named ( merchant_id ) it belongs to the parent of merchant.
id - name - email - password - merchant_id
The second:
Make a separate table like ( employees ) that the merchant has many employees.
id- name- email - password - merchant_id
The problem that I'm confused with is like when I give the employees permissions!
please guy's any suggestions for something like this probelm ?
I created a diagram to show my point of view. Please consider the following image:
Explaining the diagram:
A merchand hasMany Employees;
An employee belongsTo a merchand (foreign key merchand_id to tbl_merchands);
An employee belongsTo a permission (foreign key permission_id to tbl_permissions);
A permissions hasMany employees;
Code the relations in the models and you are good to go. To validate if a user has permission to access some Route(), you can use a middleware.
NOTE: I created a tbl_permissions because of your request. Maybe I would rename to tbl_groups (admins, users, etc) and use the table globally.
Hope it guides you. Regards!
COMMENT #1:
To control the page access you may use a middleware. You can create a table for products with foreign keys to merchand_id and employee_id. To get products associated to an employee, you need to create a Model plus the relation to the products. To retrive the data, do Employees::find($employee_id)->products. Hope you know how to code in laravel otherwise you will have an hard time coding this tips.
Related
I have created a database with many tables but at the moment, i am concerned with 3 of the tables i have. Company table, Manager table,Customer table.
Now every company has one manager to use the application so with that, it has a one to one relationship and the table looks like this
Company
name
email
phone
manager_id
Manager
id
name
But then, every company can have lots of customers and each customer can belong to more than one company. In respect to that, i made a many to many relationship with the manager table to create a pivot table.
Because i want to avoid duplication, in the customer table, phone is primary. Will this relationship avoid the duplication. I want to be sure of this before i start writing my codes..
I am a newbie with database design. Thank you
Manger_has_customer
manger_id
customer_id
PS: This is how the customer table looks like
Customer
id
name
phone
I have an application where a User can be a Supplier or a Shop.
Now these 2 roles have very different role-specific fields..
Basically, a Shop can make Orders to Suppliers.. So a Shop can make Orders and a Supplier will receive those Orders.
Where would I put these fields for good practice?
Add them all on the User class, with nullable types (doesn't seem right!)
Create a different class for each Role. So we have a Supplier class with a user_id and Shop class with a user_id, I would have to query these fields using $user->supplier->field or $user->shop->field...
Neither of these seems like thé way to go. Any idea's?
Thank you!
You don't have to stick with a single users table. You can have a Supplier model and a Shop model (with suppliers and shops tables).
Then in the config/auth.php file, you can set up a new auth provider using the Eloquent driver but with a different model. You can then assign those providers to any new guards that you create.
You can read more about authentication and authorisation here:
https://laravel.com/docs/5.4/authentication
https://laravel.com/docs/5.4/authorization
Edit
After it was mentioned in the comments about polymorphic relations, I think that would apply better for this type of relationship (multiple types of users, each with own set of fields).
Read more here:
https://laravel.com/docs/5.4/eloquent-relationships#polymorphic-relations
Can a user have multiple shops or supply multiples? Your second option seems fine.
User hasMany: supplier, shop
- id
- name
Supplier belongsTo, hasOne: user
- id
- user_id
- fields_supplier
Shop belongsTo, hasOne: user
- id
- user_id
- fields_shop
$user->supplier->fields_supplier;
$user->shop->fields_shop;
$supplier->user->name;
$shop->user->name;
--
If you had more info on how you wanted it to work, it would help.
"Supplier" is a role played by a "Party" ("Individual" or "Organization")
Your store may get a Catalog from a Supplier, and may Request Quotes from them.
Your store creates "Purchase Orders" and sends them to the Supplier, and they send you "Order Responses"
A Supplier is not a user. You could create "User"s for their employees though
Why not just use an existing ERP like Odoo?
I am building a real estate related website that real estate agents and investors can use to track properties submitted in the system and keep track of who is owed what profits. I have the following tables that I am having trouble figuring out how to setup the relationships for in my models using PHP ActiveRecord:
properties
id
primary_profit_sharing
secondary_profit_sharing
commission
referral_payment
users
id
name
email
payments
id
type (commission, referral_payment, etc.)
property_id
user_id
What is the proper way to setup these relationships using PHP ActiveRecord? I would like to be able to access the user information for each payment by something like $property->commission and $property->referral_payment but I can't figure out how to setup the relationships in the models to allow that.
I currently have payments belonging to users and properties, and users/payments have many payments. All the information I was is returned in the query, but not in an accessible ways. I have $property->users but no way of getting the user information for a particular payment type.
The only way I can think of to accomplish what I'm looking for is to setup a table for each payment type, but that doesn't seem like the best way to do it.
In the payments table, instead of using property_id and user_id, maybe you should use fk_object as the foreign key and do your joins using that field. fk_object represents the id of the user or the id of the property.
I am developing a social network for an intranet, and I came across a problem [?]. I have the entities User and Business as main entities of the network.
Note: A Business does not have, necessarily, a relationship with a User.
Following this idea, I have a group table, and a group can be created either by a user or by a business, there comes a question, how can I make the author field in this table?
I did the following, I created a table type, with the following data:
id | name
1 user
2 business
And my table groups like this:
id
name
description
tid (FK -> type.id)
author (INT)
Thus, if a group has a tid equals to 1, means that the author is referring to a User, if it have tid equals to 2, it is referring to a Business.
What do you think about this implementation? It is correct?
What can I do to improve it?
I'm using PHP 5.3.6 (Zend Framework and Doctrine2) + MySQL 5.1.
Per request:
The terminology for this is "polymorphic". Bill Karwin had a good answer that I can't find at the moment about it. From a database design perspective, I've been told the logical model term for this is an "arc" relationship. Either way, I see no issues with what you posted, other than supporting multiple authors.
The bad thing about this is that you cannot use the foreign key constraints to check and verify your data if you do this.
I would recommend using 2 tables instead. one to store the relationship between user and group, and one to store the relationship between business and group.
This will allow you to use all the fk benefits like cascading deleted when the group or business or user is deleted.
I'm going to allow companies to register on my website and create job listings.
I'm currently approaching the problem by creating a Company table with Name, Logo and Password fields. Then when a person registers he can say, "I belong to X company"; at this point, I'll request the password written in by the initial registrator. If she/he enters the correct password then he is given permission to create job postings in the name of the company.
Why I'm doing things this way:
If I just put everything inside of the Company table, every new user would have to create an account and I'll have redundant information, CompanyName, Logo, etc.
And if I do things without a password, anyone can post a job opening under a companies name and that's just wrong.
Care to share some input? Am I doing things wrong? How would you do it?
I would do "jobs requests" like Facebook's friend requests and if the user really work in that company, the company manager just has to login and confirm it.
Database Normalization.
Create a separate Users and Companies table. Can one user post for multiple companies? if so, you need a many-to-many relationship (which requires a third table to keep track of the relationships). Otherwise, a one-to-many should work.
You should create two tables:
Company:
- id
- logo
( - name, etc )
User
- id
- companyId (foreign key to Company.id )
- password
( - username, etc. )
This way a User is a child of a Company identified by companyId. Now, if a user logs in, you can identify what company s/he belongs to by finding the Company corresponding with the companyId. Now you have a password per user, and a company per user.
And like Jimmy says, if you need Users to be able to be part of more Company's you would get:
Company
- id
- logo
User
- id
- password
Company_User
- companyId (foreign key to Company.id )
- userId (foreign key to User.id )
in my opinion you should create table like
Employers:
eid(pk)
logo
Username
Password
profile
etc....
JobSeekers:
jid(pk)
Username
Password
etc...
JobPosts:
id(pk)
eid(Fk to Employers.eid)
JobTitle
Specifications....