I'm fairly new to MySQL and PHP, but I'm getting the hang of it slowly.
I'm working on a site with profile pages. I have a users table in my database and I intend to create a profile table too.
Before I explain my 'problem' I'd like to say I haven't actually began coding an attempted solution. I like to plan my work before I start it, especially when it is going to be complex. Therefore, I can't really display any snippets of code.
What I would like to create is a tagging system for the user profiles. ie. let the profile owner select keywords from an existing list, and associate them with his profile page.
After pondering plenty and reading up on relational databases I gathered I should start by creating two additional tables:
1. tags (tag_id, tag_name)
2. tag_rel (tag_id, user_id)
and create a relationship between each profile to the different tags a user assigned to it, on seperate rows:
(Tag1, UserA)
(Tag2, UserA)
(Tag1, UserB)
etc.
Then when I search for profiles I simply have to select all user_ids with a specific tag_id. Easy enough.
My issue is the PHP and MYSQL Query code when inserting or changing the list.
I would essentially want the user to be able to either choose from a check-list or from a drop-down select list (or anything equivalent) of existing Tags, check or uncheck his selection, and send to enter it to the database.
I can imagine the initial entry of the selected tags is easy enough to achieve with a foreach() function and a simple INSERT query, and enter the array from the form one value at time.
But when the user goes back to change the tags, how would I instruct a query to keep some tags, delete others, and insert new ones in? What is the best method to do something like this?
An Idea:
Should I delete all the existing rows the user has in tag_rel, and insert the new array?
I would use a procedure like this:
at first you fetch the tags a user selected out of the db and pass them to an array (SELECT from tag_rel where user_id = $userId)
then you would go over to let the user operate on the array (adding new tags, deleting old one)
at last you would delete the old entries and insert the completely new ones from the array provided
the simplest method is to delete tag_rel data for that particular user_id then re-insert the new ones
Related
I want to maintain the history table for my application to track what all the fields were changed by the user.
The following is my bugs_history table structure -
id, bugsid, userid, field_changed, old_value, new_value, created_on, created_by
So my query is, when I'll update my form and submit, how to get the field name that was changed along with old value and new value. And add the modified changes in the above history table.
I have googled a lot for this but didn't get as per my requirments. Please let me know how to achieve this.
If you know the field names (you have a HTML form containing them, so you probably know the names) then build a list of them that you then loop through, building a new SELECT query to get old_value and then an INSERT query to save it. The select would order on created_on DESC and LIMIT 1.
But I see a clear problem here: concurrency. What happens when two users try to edit the same bug (with the same bugsid) at the same time? They would expect the old_value to be the same for both? Or should the two operations be executed sequentially? Or should the last one to edit be warned that he's trying to edit stale data? Which one would get the "latest" created_on?
This right here is your real problem, not writing the code that generates two SQL queries.
I am storing user ID values in a table field separated by a | (user_id1|user_id2|user_id3|user_id17).
A user ID will be added and removed from this field at certain points.
How can I check if the current users ID exists in the field or not using a query?
And it of course needs to be an exact match. Can't look for user_id1 and find user_id17.
I know I could use a SELECT query, explode the field, then use in_array but if there's a way to do it using a query it'd be better.
I guess I'll explain what I am doing: I made a forum for a small private website (7 users), but coding it for larger scale.
My table structure is pretty good: forum_categories, forum_topics, forum_posts. Using foreign keys between the tables for delete and update queries.
What I am seeking help on is to mark Topics as unread for each user. I could create a new table with topic_id & user_id, each one being a new row but that wouldn't be good with alot of users & topics.
If somebody has a better solution I am all for it. Or can prove to me that 1 row per user_id is the best way then I'll be more than willing to do that.
I think you want to track read messages, not the other way around. If you tracked unread messages, every time you add a user you'll have to add that user to every topics "unread list".
I looked into SMF like my comment suggested. They are using a separate table to track read messages.
A simple table that holds user_id and topic_id are you are need. When a user reads a topic, make sure there is a row in the table for that user.
Another reason to use a separate table. It's going to be faster to query against 2 int values in the database than to use LIKE % statements.
When creating a many to many table, relational database. If for example you are enabling users to scrape images form around the web and tag them.
Would it be better to:
Check to see if the image is already in the database and if it is, create a link in a relational table and if it is not create a new image.
Create a unique instance of the image for every user and when looking to display the most popular images SELECT AND ORDER BY the image with the most duplicates
I hope this makes sense. Thanks in advance for you help.
I assume you have something equivalent to a USERS table and a PICTURES table. Also a table to break up the many to many relationship. U2P I will call it.
The option you listed as option 1 would seem to be the preferred way. Check to see if the picture is in the DB, if it is get primary key from PICTURES corresponding to it. If not, put the picture in the PICTURES table.
Regardless of if it is a new image, or one that is already in there, you will insert the event into the U2P table. This would reference the USERS primary key and the PICTURES primary key corresponding to the event. You would also record other data such as time etc...
I am working on creating a favorites section on my website where users can simply store certain items in their favorites section for easy access. Each of the items are already well-defined and have multiple attributes. So my question is lets say I had 10,000 users and I would like to implement a 'favorites' system, what would be the best way to keep track of what favorite items have been added by each user?
I was thinking implementing this the following way: link each favorited item id to a username and then run a query for if the user with a particular username is logged in than retrieve all the favorited items by that username.
I appreciate any help with figuring out of a good way to do this. My goal is to store in a way that is later easy to retrieve and use the data and minimize redundant information.
It's pretty easy, you need to create a new table with 3 fields:
id
favoriteID
userID
Every time a user adds a new favourite, it adds a new record to this table, storing both the ID of the favorite, and the ID of the user. There is no redundant information and it's easy to retrieve the details of either the favorite or the user by implementing a join query. This is what relational databases are for.
Within an RDBMS you would probably have a many to many table with the user id and article id. You do not need an independent id column:
create table favourites (user_id int, article_id int);
These of course reference your user table and articles table. (Or whatever you have in place of articles.)
You would then need to retrieve all rows for a single user when wanting to show that user's favourites. You might also want to make a combined UNIQUE index on the columns to prevent duplicates.
You may have faster response with something like cassandra where you can simply retrieve based on the key of the user_id and get all their favourites in one easy spot. But then you're dealing with mutilple systems.
I've heard, but haven't had a chance to look into, that MySQL can now support a Key-Value system similar to Cassandra and that may be your best bet.
I have an application that allows users to enter reports, there are multiple tables that keep track of the data.
I am working on making an edit form to allow the user to edit an existing entry.
I need help with handeling the update query. Not the actual query, but understanding the best way to handle this.
For example:
A user adds an entry, they could select multiple departments.
Next, they edit that same entry, and select more departments and unselect a couple departments (from when they originally added that entry).
There is a table that keeps track of the entry and what departments it relates to: entry_id, department_id
When doing an update query, how do I update that table appropriately? Do I delete all entries where entry_id = 4 (just using any old number), and then just do an insert w/ all the departments that were selected? I am looking for best practices.
I am not asking for code that does, but just theory.
That looks like a good strategy to me. The alternative is to get the set of existing IDs, remove the IDs of this set that are not in the new set, and add the IDs that are in the new set but not in the old one.
But unless you need to keep some additional metadata on the association (time of creation, for example), the delete all and recreate approach is much simpler.