I wondered how a table should be structured when there is going to be more than one value for a certain field. For example, If I have a user who has 10 friends should there be a table that has 10 rows with the user's name and a different friend on each row or should there be one row with the user's name and all the friends put into one? Thanks, the answers will help a lot.
You should make a many-to-many table that links the foreign keys together of two people who are friends. So if Person is the entity you are using, you wouldn't want to constrain the structure by introducing limitations such as 10 friends into a single row.
Fundamentally, what you're trying to do is normalize your data. You should read up a bit on Database Normalization
Related
I have to create a system to save user's vote for two different type of module: News and Video.
This table should have the same fields:
id
entry_id
vote
user_id
So I tought to add a new field to save also the name of the module (module), in this way I can have just one table in the DB and filter it when needed and create two views for statistic purpose.
I don't really know if the best solution is one table with the new field or is better have two different table.
Let's assume that I have 1000 news and 1000 users and all of them will vote each news I will have 1000000 rows in the table.
Now assume that I have also 1000 videos and also in this case all my users will vote it, other 1000000 rows for an amount of 2000000 rows in a single table.
Do I have any performance problem in this case? And If I will have much more video, news an users?
Operation that I should do:
Insert
Update
Search
If you need more infos please ask
I think the way to answer this question is based on entry_id. The votes are going to be about something and that something is going to reference another table.
So, if you have two separate tables for News and Videos, then you should have two separate votes tables. Neither will have entry_id. One will have news_id and the other video_id.
If you have one table, say Entries for both News and Videos, then have one table.
In other words, I am advising against having one table conditionally reference multiple other tables. It becomes very difficult to express foreign key restraints, for one thing. In addition, join operations are cumbersome to express. Someone else might visit the table and not realize that entry_id can refer to multiple tables, and incorrectly set up queries.
All of these problem can be overcome (and there are situations where one table may be the preferred solution). However, if the original entities are in different tables, then put the votes in different tables.
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.
I am curious to know what would be the preferred method for a table which would store a list of IDs associated with a UserID.
Should I have one field storing a serialized array of all the id's (one row per UserID)
Or one row for every id for every player? Is the answer clear cut or are there factors to take into account when making such a decision?
Hope you can help explain the best choice.
if you're going to get the whole list of IDs everytime or most of the time, or if the lists of IDs are short, then serializing them is fine (though I wouldn't recommend it anyway)
However you'll be missing out on indexing if you ever need to search for a user using an ID in the list of IDs as a constraint.
Best way is to have a separate table storing the many-to-many relations (which is what I'm assuming you want). If you have a one-to-many relationship, then you should reverse the way that you are referencing the relation and add a user_id column to the table containing the IDs .
I would keep one row for every id for every player. That to me is more manageable and clean approach. How many records are you looking at here though ?
I want to develop a social networking site, where users can make friends with other users, and I have the following example table:
Table Name : Friends
id | friends
id will contain the id of the user and friends will contain the ids of the user's friends in one row. The id column will be unique and primary key.
My Question
I would like to know if I can store the list of friends as a serialized array as that would limit the friend connections to only 1 row per user as against other methods described in here, which is have friends table, and insert user and friends id in each row.
During retrieval, I would unserialize the row and put it in an array.
You can do that but you'll then have to always keep it updated and there is no way to join on that information or search it accurately within a mysql query.
With an app like this you WILL need that data to be available.
If you're not comfortable with the SQL required to join the tables in the proper way just ask for help with the point of confusion / frustration =)
It can be done, but there is no advantage to it. It will be difficult to do aggregate functions, for example summing or finding the newest friend will be almost impossible. Doing joins will be impossible, without unserialising through code and making new queries. Also, you need to change the structure a bit:
Table Friends
ID | User_ID | Friend_ID
1 4 5
2 4 6
ID would be an auto-increment primary key, user id is the id of the user and friend id is the id of the friend
You shouldn't concat data (foreign id's) into an single field in an relational database. You won't be able to join/select any data. Instead use:
friends
userId, friendId
This would totally break the idea of a relational database.
You could also have a single table - person and storing on the first position the id of the person and the friends serialized after that.
The idea is that you can not make simple queries on those "database structures" like counting the number of friends, regardless to say common friends or other simple operations.
Anyway, I would recommend you to take a look at some Graph Databases and consider unsing one for your social graph
I'm new to programming so forgive my simple questions.
Basically, I have two different tables containing data related to one another. I'd like to create a new column called "id" which will associate rows in both tables so that I can appropriately display the data.
When a user takes an action, a row is inserted into both tables.
What kind of properties should "id" have? Primary key, auto-increment on both tables or one table? How do I ensure that the same ID is inserted into both rows, do I insert into table1 first, then grab that ID and insert into table2?
Any help appreciated. Thanks
It's somewhat difficult to answer your question without knowing what the two tables contain, but I suggest you read about database normalization.
Regardless of how many tables you decide to have, each table should have an id column of some sort. Having a way to uniquely refer to a single row makes life a lot easier down the road when you need to make changes to the data. Auto-increment saves you from having to come up with your own unique primary key values.