I am trying create a schema for profile management system.
Since each profile will belong to different category for example sports,political ,non profit organization etc.
Each profile contain different info or details from one another so
1.My question is it better to create all columns in single table or creating different tables for each category because if i create in single category it will be large columns in mysql when category will increases or each category may come some related tables ?
users
id | first_name | middle_name | last_name | dob | primary_email | secondary_email | password | primary_phone | secondary_phone | home_address |
profile_categories
id | category_name |
user_categories
id | user_id | category_id
political
id | category_id | political_person_name | .....
Related
I am trying to develop an e-commerce website in Laravel but I am having trouble with sorting the data of a category. I tried it through eloquent but unable to sort by price. I tell you my database table structure.
Table category
id | user_id | name | slug | description | timestamp
Table product
id | user_id | name | slug | content | tags | extras | feature_image | timstamp
Table category_product_relation
id | category_id | product_id | timestamp
Table product_price
id | product_id | price | tax | discount | quantity | timestamp
Now, I want to sort products of a category by price. Let me know if this db structure is good or not. If it is not good kindly guide me.
I've created a database using MySQL with PHP as it's front end. And for end users I've created a username table and data excess level table, I've also created a table in which I've linked usernames with the products against which I wanted users to see their respective products only. It was executed flawlessly, but it only pick the first product of each user and leave the others.
I am thinking to create a separate table with the name of group in which I can link it with username and excess level table. But I am unable to think of a way to do this.
Any better idea to do this without any difficulties?
Table structure:
--------------------------------------------
| username | product_user | excesslevel |
--------------------------------------------
| usernameid | pu_id | excessid |
| username | productname | excesslevel |
| password | username | username |
|-------------|--------------|-------------|
------------------------------
| username | product_user |
------------------------------
| userId | pu_id |
| username | productname |
| password | userId |
|-------------|--------------|
If I userstand this correctly... A user can only access their own products.
If that is true, query your database with:
SELECT * FROM product_user WHERE userId = 1
This would give you every products that belong to user 1. A third database would be required to assign a same product to different users.
Also, don't use the username in another table. If the username change, you'll need to update many rows from different tables. Assign it's ID instead.
Here is my pivot table project_group:
+-----+----------+------------+----------+---------+
| ids | group_id | project_id | admin_id | user_id |
+-----+----------+------------+----------+---------+
| 4 | 115 | 1 | 1 | [3,4,5] |
| 5 | 115 | 2 | 1 | [5,2,1] |
| 6 | 115 | 3 | 1 | [1,3,6] |
This table represent group linked to the projects....user_id is which users can see projects/group... Is there any way to display correct projects/group only to the users defined in user_id?
Also content in user_id field can be changed....
The best way to handle this would be to first normalize your database. Storing comma separated lists in a cell is allowed, but generally bad practice, as explained in this question.
If you can have multiple users per project, you should have a linking table with a column for project and a column for user, like this:
project_users:
| project_id | user_id |
and you can make (project_id, user_id) a composite primary key.
That way, you can select the users for a project (say, project 1) like this:
SELECT user_id
FROM project_users
WHERE project_id = 1;
Once you have these, you can display the project data only to users whose id is returned in the above list.
I have built an SQL Fiddle that helps demonstrate this visually, if it helps.
It is good to note that this proper normalization gives the opportunity to a lot of useful data as well, as it becomes easier to search for users by project, but also you can search for project information based on a user.
I'm trying to find out the best way store array of items with details in SQL table.
I have a user account database. The user have multiple input fields to enter multiple details like:
___ : ______ +(get more multiple field field)
User can input any details like
Output1 : Output2
Mobile : 2455...
email : sdf
city : dfs
Other : sf
On an average a user will use around 20 options
Since the fields (mobile, email etc.) are not known to me, I have to store Output1 field with the answer field (output2).
I will be having a very huge user base, so I think it's not better to create separate tables for each user.
Is there any way to store and get the details in limited or single column.
Since both the attribute name and value comes from users, a typical 3-table model of saving many-to-many relationship is a bit of overkill.
I would just kept users and their attributes in two separate tables:
+---------+-----------+--------------+
| user_id | user_name | user_email |
+---------+-----------+--------------+
| 1001 | John | john#doe.com |
+---------+-----------+--------------+
| 1002 | Tim | tim#doe.com |
+---------+-----------+--------------+
+----------+-----------+--------------+--------------+
| field_id | user_id | field_name | field_value |
+----------+-----------+--------------+--------------+
| 1 | 1001 | Option1 | Option2 |
+----------+-----------+--------------+--------------+
| 2 | 1001 | Mobile | 2345656565 |
+----------+-----------+--------------+--------------+
| 3 | 1001 | city | dfs |
+----------+-----------+--------------+--------------+
| 4 | 1002 | Other | something |
+----------+-----------+--------------+--------------+
Possibly with some additional columns for sorting, tagging, etc.
I would use 3 tables.
Table 1 - user. PK is UserId. Other fields are name, rank, serial number, etc
Table 2 - Attribute - Primary key is AttributeId. Other Field is attribute name. Examples of attribute names are emailAddress, cellphoneNumber, cityName.
Table3 - UserAttribute. Primary Key is UserId and AttributeId. Other field is Attribute value.
In my business logic, I have a user, a company (users can be part of the company, as employees, i would call them "agents") and products.
A product can be owned by a user or by a company, the company can assign it to a user (agent) later, but it would still be owned by the company (in case the company fires the agent).
My thought is to have the user table, the company table and the product table and a table to track who is the owner of the product:
--------------
| users |
--------------
| user_id |
| name |
--------------
--------------
| products |
--------------
| product_id |
| title |
--------------
--------------
| company |
--------------
| company_id |
| name |
--------------
--------------
| agents |
--------------
| agent_id |
| user_id |
| company_id |
--------------
----------------
|product_owner |
----------------
| id |
| product_id |
| user_id |
| company_id |
|agent_assigned|
----------------
If the product is owned by a user then only product_id and user_id will be filled. If it's owned by a company, then product_id, company_id and agent_assigned would be filled.
Later, I would want to pull a product, and know who's the owner: the user info, or the agent and company info.
Is this the best way to do it? It doesn't seem that good to me.
Use the standard Party Model. Read up on Table Inheritance to implement it.
An asset is owned by a legal party. It could be an individual, group of individuals (say the Jones family), a government, a company. You need to abstract these concrete types to one abstract type so that you can point a single foreign key at them.
Based on your requirements I don't think you are too far off. I would separate the products that belong to company and user however and make it into something like this:
Then when you need to pull a product and find the owner you just need a join query. Something like this:
select * from product p
left join companyproduct cp on p.id = cp.product
join productowner po on cp.productid = po.productid
join agent a on po.userid = a.userid
where p.id = ? AND a.userid = ?
I'm not saying that syntax is correct or will work for you, it is just an example of what you would need to do.