Information:
I have 2 tables(users for the users of the website and new_themes for themes/posts(whatever) created by the users.
!!!There is no relationship between these 2 tables.(A user can create a new post if he is logged in)
Tables:
Users:
1 id
2 name
3 email
4 password
New_themes:
1 id
2 title
3 text
4 upVotes
5 downVotes
6 TagName
What I want to do:
I created the feature that user can like the post(but he can like it unlimited number of times) but I want them to be able to like just once in a life time a post.
What I can't figure out is the idea/structure/logic of how to make it. I am thinking of creating a table . A "pivot" one for tables users and new_themes(many to many relationship in Laravel)
1 id_user
2 id_theme
Where the both of them have a composite primary key so they won't be any duplicate values, so if the user wants to vote once again the same post he won't because there can't be duplicate values.
Here is the problem:
If this is the solution, I have doubt and no idea on how to populate the pivot table when a user likes a theme. If this isn't the solution any advice or idea will be very helpful for me to finish my last feature of my wep app.
Thank you very much.
What I can't figure out is the idea/structure/logic of how to make it. I am thinking of creating a table . A "pivot" one for tables users and new_themes(many to many relationship in Laravel)
That's the way to go. So it would look like this:
+---------+----------+
| user_id | theme_id |
+---------+----------+
| 1 | 1 |
+---------+----------+
| 12 | 1 |
+---------+----------+
| 14354 | 1 |
+---------+----------+
To 'like' a theme, just insert the user and theme id into the table. The rest is just taking care of the response from the database - giving the user feedback for his try to like something more than once etc.
And of course you should not forget the ability to unlike - so you need to delete from the table again... if you want users to unlike.
First you have to create a new table with following fields (id, user_id, theme_id, status) as you said, maintain the relation between user and theme in that table.
when user like the theme insert a record with status 1 , if user unlike the theme, first check the user_id in the table, if user id is present then just update the status to 0 otherwise insert new entry with status 1.
Related
I'm making an online game for a mounth i guess. I made user profiles, forget password, manage your account pages. And when they enter the game they can see their names and some information abut each other. Never mind of that.
Now, i need to do items for each users. So, here is my mysql table:
user_id | name | email | password | color | items | head | face | body | hand | feet | created
But i can add just one value into items col. How can i add all the item id's the user have? Please someone help!!!
You need a second table. Remove the "items" field from this table and create a new table called Items. In it you will have:
primaryKey | user_id | item
Then to get every item a given user has, you perform a SQL SELECT WHERE user_id=#id and iterate over the results.
There is a one to many relationship between the user and the number of items the user can have. You need to create another table with the following columns
user_id
item_id
item_desc
and store the item information there
You can store the ids as serialised arrays or create an user_item table.
I am working on a shopping cart website,
I created a table to display to the user tp order like this:
+---------------------------------+
| My order list |
+----+------------+---------------+
| ID | NAME | ACTIONS |
| id | name | update delete |
| id | name | update delete |
+----+------------+---------------+
The problem is I identify the edit item like this:
mydomain.com/product_list/edit/1
Where 1 is the table ID of the product list
It is really dangerous as other user can delete the records of other by trying to tamper the id. How to secure this one? Even by posting, the hacker can just create a fake posting page, and post the fake id to the program.
Thanks
I've read your question and comments. And I think storing owners of tables in another table can help you (if I get you right)
You said
since the order id is just by number , e.g. order id 1 is the first record for customer A , order id 2 is for B, 3 for A etc... so if user B type in / post 3 as parmeter then he can delete the record of user A
Before you let me alter the table, you have to check if I've permissions for this. You can check my e-mail, my password, add them to session etc. But when it comes to check query string, you can simply look if this table is one of my tables.
So if user B type in / and post 3 as parameter, you can go and check if B is one the owners of table 3. If no, don't let B do anything.
This is a bit confusing. I cant find how to word it for google and I just cant wrap my head around the logic to do this.
I have "contacts" and "sites" tables that I am storing data for in a database. We need to have a page showing the contacts information and what "sites" they are associated with AND have a page for information about a "site" and show what contacts are associated with it.
Right now I have a field for "contacts" that has comma separated ids of each site that its associated with and a field for "sites" that also has comma separated ids of each contact associated with that site.
When I create a new site with an associated contact. how should the logic go that will update the "associated sites" field on the contacts row in MySQL while also updating its own "associated contacts" field?
I think, you are speaking about many-to-many relationships.
I assume you have a table design like this:
tbl_contacts tbl_sites
id | full_name id | label
1 | John Doe 1 | my website
3 | Maria Doe 2 | super website
You need a table to "link" the tables. this is a many-to-many-table:
tbl_contacts2sites
id | contact_id | site_id
1 | 1 | 2
5 | 1 | 1
3 | 3 | 2
So, John Doe is assigned to both sites, but Maria only to the "super site".
This is the common way to design your relationships. You should avoid any comma seperated lists for this kind of relationships.
The best solution would be when you create a third table (contacts2sites) in this table you have three columns called: id, siteid, contactid.
In this table you can add every connection between sites and contacts. To query the data out of it you can use the mysql query with joins over all tables.
little example:
solution with joins
How would things like customer reviews be stored in a database? I cant imagine there would be rows for each item and columns for each review as one product may have 2 reviews and another may have 100+ - id presume they were stored in a separate file for reviews but then surely not one file per item! I dont know enough about storing data to be able to figure this one out by myself!
A similar situation is something like an online calendar - there is all the information about each appointment (time, duration, location, etc) and there can be many of these on each day, every day, for all users! A logical way would be to have a table for each user with all their appointments in, but at the same time that seems illogical because if you have 1000+ users, thats alot of tables!
Basically Id like to know what the common/best practice way is of storing this 'big dynamic data'.
Customer reviews can easily be stored by using two tables in one-to-many relationship.
Suppose you have a table containing products/articles/whatever worth reviewing. Each of them has an unique ID and other attributes.
Table "products"
+-------------------------------------+
| id | name | attribute1 | attribute2 |
+-------------------------------------+
Then you make another table, with its name indicating what it's about. It should contain at least an unique ID and a column for the IDs from the other table. Let's say it will also have an email of the user who submitted the review and (obviously) the review text itself:
Table "products_reviews"
+--------------------------------------------+
| id | product_id | user_email | review_text |
+--------------------------------------------+
So far, so good. Let's assume you're selling apples.
Table "products"
+-------------------------------+
| 1 | 'Apple' | 'green' | '30$' |
+-------------------------------+
Then, two customers come, each one buys one apple worth 30$ and likes it, so they both leave a review.
Table "products_reviews"
+-------------------------------------------------------------------------------+
| 1 | 2 | alice#mail.com | 'I really like these green apples, they are awesome' |
| 2 | 2 | bob#mail.com | 'These apples rock!' |
+-------------------------------------------------------------------------------+
So now all you have to do is to fetch all the reviews for your apples and be happy about how much your customers like them:
SELECT *
FROM products_reviews
INNER JOIN products ON products_reviews.product_id = products.id
WHERE products.name = 'Apple';
You can now display them under the shopping page for apples (just don't mention they cost 30$).
The same principle applies for things like an online calendar. You have one table with users, and many tables with other stuff - appointments, meetings, etc. which relate to that user.
Keep in mind, however, that things like meetings are better displayed in a many-to-many table, since they are shared by many people (usually). Here's a link that visualizes it very good, and here's a question here on SO with sample code for PHP. Go ahead and test it for yourself.
Cheers :)
I am currently developing a Student Information System that is going to be used by educational group to provide students & teachers a portal.
I am using Laravel4 which has a good authentication driver built in but can use only one table for authentication. I am unable to figure out how to authenticate them because I have users in multiple tables. Example :
SchoolOne_students
SchoolOne_teachers
SchoolTwo_students
SchoolTwo_teachers
and so on....
A significantly better way, rather than multiple users tables, would be to link each user to their school and status (teacher or student). You certainly can twist Laravel into doing what you want, but in order to prevent conflicts between the four different user types, you'll probably end up having to rewrite a large part of the entire authentication package.
What I would do is, in your users table, have an ENUM column, with the options student and teacher. Then, have an integer column, school_id (with a separate table for school data, if needed). This will allow much more flexibility, and when your design requirements change (yes, they will change), you'll be able to take them in stride.
Using this method, you should not have to modify any of Laravel's own code.
if all the tables have identical schemas, you could create a view that does a UNION of all the tables and then use that view as your Laravel auth table. I am not saying this is an ideal solution, but if you have restrictions on altering the existing tables and must use them as is, this could work.
The view would not be update-able (I don't believe so, at least) so adding or updating users would require specific add/update code, but for Auth, this may do the trick.
CREATE VIEW users_combined_view
AS
SELECT id, username, password
FROM schoolOne_students
UNION
SELECT id, username, password
FROM schoolOne_teachers
UNION
...
note - this method would be somewhat useless (ok, totally useless) if username was not unique across the tables
A good database design is scalable.
This is particularly a bad idea:
SchoolOne_students
SchoolOne_teachers
SchoolTwo_students
SchoolTwo_teachers and so on...
There should be only one table for all the users, in your case for students.
There should be another table for Schools where all the school information will be stored.
Then you should join the students table with schools table by adding a school_id field to the schools table where the school_id will be stored for the corresponding students row.
===Students Table===
+-----------------------------------------
+ id | name |school_id | ... | ... |
+----+--------+----------+-----------+----
+ 1 |Student1| 5 | ... | ... |
+----+--------+----------+-----------+----
+ 2 |Student1| 3 | ... | ... |
===Schools Table===
+-----------------------------------------
+ id | name | ... | ... | ... |
+----+--------+----------+-----------+----
+ 3 |School 3| ... | ... | ... |
+----+--------+----------+-----------+----
+ 5 |School 5| ... | ... | ... |
+----+--------+----------+-----------+----
This way you can add as many schools as you may want and students for them
I hope this will help