I'm building a small survey application in Laravel and I'm not sure how to structure the database. There are three main entities for it:
Users
Surveys
Questions
A user can fill in many surveys and a survey can have many questions. For this I'm creating two pivot tables:
user_survey (id, user_id, survey_id)
survey_question (id, survey_id, question_id)
But I'm not sure how to store answers as a user may also fill out the same survey multiple times so there needs to a way differentiating between different versions of a users answers.
My thought at them moment would be to create an additional table called user_survey_answers with the following columns:
id
survey_instance_id (will reference the id column from the user_client table)
question_id
question_answer
Would this be the best structure to use for this? If so, how would I create the eloquent relationships within Laravel to reference the user_survey_answers table?
Related
So my question is very much just a database design question. I'm relatively new to PHP, taking my first database course, and I'm trying to figure out how best to execute my idea.
So I'm building a membership database. Within this database there are "members" and there are "meetings," represented as two separate tables. I'm wondering what might be the best way to add a list of members to a meeting instance, or create a relationship table between the two. For example, would you advise that each member ID (primary key) be added individually (say, via a bunch of text input form fields) when creating a new meeting instance? Or perhaps is there a way to easily have the user upload a CSV or excel file of primary key user id numbers and, from those user number ids, easily create a relationship table?
Hope this is clear- just hoping to get some advice/insight, perhaps I'm not aware of the easiest way... Thanks!
I don't know what are you trying to do in your particular case, but is sounds to me that you should have three tables:
members - you have that one already
meetings - you also have that one already
members_meetings: this one is the table, that will join the two tables. And the required fields in that table should be:
member_id - the id of particular member, points to the id field in your members table
meeting_id - the id of the meeting, this member is attending, points to the id field in the meetings table
Than, if you want to get all members, that are attending meating X, you can just run the following query:
SELECT members.* FROM members_meetings LEFT JOIN members ON members_meetings.member_id = members.id WHERE members_meetings.meeting_id=X
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a small app in php using the cakePHP framework connected to mySql database.
I have two types of users (business and employees) with relationships to other tables also. I am now adding a login facility which means I will be adding a users table to hold the password details. So both employees and businesses will be able to login.
I am not sure what way to add the relationships between the users table and the businesses and employees table. I will be adding an admin role also.
My current tables are:
- course_files
- course_modules
- courses
- courses_employees
- employees
- businesses
My Choices:
Merge the businesses and employees table with the users and have a
users (id, role employee_name, business_name, business_address, etc)
roles (admin, employee, business)
My issue with this approach is that the fields for businesses and employees are very different so the users table will have a lot of fields. But it will make it easier for the login functionality.
Add business_id and employee_id to the users table. This option will be a little more involved and one field will always be blank like employee_id.
users (id, employee_id, business_id, role)
roles (admin, employee, business)
employees (business_id)
businesses
So before I go down one route and find I went in the wrong direction I was wondering what would be best practice?
I disagree with both of your approaches. I would have a users table for login, and tables for employees and business, just like you suggested in your second approach. The difference is that I wouldn't have employee_id and business_id in users because, as you've already stated, one will always be blank. Why don't you instead have a user_id in both tables, as they will always have a user profile (intended for login)? I see you use CakePHP, so these will be relationships as follows:
User hasOne Employee
User hasOne Business
Employee belongsTo User
Business belongsTo User
Let me know if any other business rules in your application make my approach hard to implement.
I came up with this database design after discussing it with many people over IRC.
In my project, a User aka Member can have many "Teams" & "Projects" on his account and can be part of some "Projects" as well. Moreover, "Teams" can have many "Members" as well including the Member who is creating it.
Now my question is, suppose, a Member wants to create a Project or a Team under his account (later on I want to see all projects created by a specific member), can I do a insert into the using following in PHP?
INSERT INTO projects VALUES(values) WHERE member_id = something
I can get the member_id using the session variable I guess.
Use regular INSERT to create the projects or teams row, then use the ID created there to insert into the projects_members or teams_members. Also settle on plural or singular names for your tables (currently you have team not teams).
Your query would be somethings like this
Insert into
table(columns)
select (columns) from
another_table
where
conditions=.
Just Remember One thing the order and names of columns must match.
If Member wants to create a Project or a Team under his account it will not be possible using current structure.
You need to add one more column created_by on projects and team tables.
The name of "team" table should be "teams".
I want to design a DB which will be connected to PHP Application. In the app there are two types of users: company and person. Some functionality like adding articles will be done by both so in other tables there are author_id columns. So firstly I decided to create user column.
That's easy: id, username, password, role, active, created where role defines whether user is person or company.
Now I want to add profile table or profile tables depends on what you'd suggest (joined with the previous table by adding profile_id column there).
Both roles have different fields, which are required during registration.
The easiest thing would be to create one table with all required fields for both roles, allow them NULL values and in the PHP app (made in Yii Framework in this case) define requirements for each role in models.
The nicest thing would be to create separate tables for both roles BUT the questions is how to connect these two tables to one table using Foreign Key? Is it even possible. I know I may omit foreign key creation then based on role choose table, and from that table choose profile_id.
Or maybe you have another solution to my problem.
Thanks in advance for replies.
Adrian
You need an intermediary between the page and the database to assign the user to a group that has specific privileges. It's usually accomplished with a user-group-role design.
You can have a table for users system info (username , pass ...), and another for users profile (firstname , birthday ...), and another for groups(superuser , ...).
where user table can have multiple groups: user:one->group:many
user can have one profile user:one->profile:one
I think this is a decent solution.
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.