I want to make an app that allows users to add other users to a personal friendslist. In my database there is a table called 'users'. Every user has a unique id and a unique username, now every user needs to be able to have a list of friends.
I think the best option to save these friendslists is to create a seperate table with two colums, for every user. One column for the friends' id's and one for their usernames.
I can search and retrieve the friends username and id at the same time. On the downside I will need to create a hugh number of tables (hundreds, thousands, perhaps millions), one for each user.
Will this make selecting a table from the database slow?
Will this unnecessarily cost a hugh amount of space on the server?
Is there a better way to save a friendslist for every user?
You should not do that.
Instead do something like
UserTable
* Id
* UserName
FriendsTable
* UserId
* FriendId
You may need to read a little about relation databases.
This way a user can be friend to a lot of people. Consider for this example
UserTable
1, Joey
2, Rachel
3, Chandler
4, Ross
5, Phoebe
6, Monica
FriendTable
1, 2
1, 3
1, 4
1, 5
1, 6
2, 3
2, 4
2, 5
2, 6
3, 4
3, 5
3, 6
4, 5
4, 6
5, 6
Here the people from Friends is all friends to eachother
I don't think you need to go down that route. If you have a table of users (user_id, user_name) for example and another table of friendships (friendship_id, user_id1, user_id2) then you will be able to store all friendships in one table. The unique id being friendship_id.
Related
I am trying to make a web app to learn chinese characters, and I want to keep record of the characters the users learn on a database.
I thought of keeping record using a words_learned column in the users table with an array that contains the character_id of the characers that already knows.
But I am a beginner so I don't know if this is efficient. Is the design right? Should I use many columns instead of an array? or is the complete design wrong?
Characters table
character_id character pinyin meaning
1 我 wo3 i
2 你 ni3 you
3 他 ta1 he
.
.
.
600 山 shan1 mountain
Users table
user_id user password words_learned
1 john 1234 {1, 5, 68, 599}
2 chuck passwd {2, 3, 5, 6, 8, 90, 160}
Generally this is normalized with another table, that would contain both a user_id and character_id.
This can be a huge table, but that's ok.
How do I Normalize this table. It has a tree like structure which is expected to grow like a tree.
By tree like structure I mean that new students, subjects, levels and chapters will be constantly added or updated or removed
I want to store the result of a quiz in this table. the quiz has multiple subjects under which there are multiple levels under which there are mutliple chapter. and Every students can take different subjects.
So is this table good for storing the results or I need to do something with this table?
In this particular case you need to create several independent tables:
Table "Student"
ID, Name
1, John
2, Jack
Table "Subject"
ID, Name
1, Math
2, Science
3, Geography
4, History
5, English
Table "Levels"
ID, Name
1, Intermediate
2, Moderate
3, Difficult
Table "Chapters"
ID, Name
1, Chapter 1
2, Chapter 2
3, Chapter 3
And so on and so on.
Then you define the relations between the tables, like this:
Table "student_subject_level"
ID, student_id, subject_id, level_id
1, 1, 1, 1 (John, Math, Intermediate)
2, 1, 2, 2 (John, Science, Moderate)
So far you have the student, the corresponding subejct and the subject's level. Since we may have multiple chapters for each level, we need another relation:
Table "student_subject_level_chapter" (or use simpler name)
student_subject_level_id, chapter_id
1, 1 (John, Math, Intermediate, Chapter 1)
1, 2 (John, Math, Intermediate, Chapter 2)
2, 1 (John, Science, Moderate, Chapter 1)
And so on and so on. Start by isolating the individual tables and then figure out how you'd like to achieve the actual relation. Fore each new relation where you have redundant data, you'd like to have new table which keeps the relation you need. It's much easier once you have ID's to refer to, so start with the individual tables and figure your way through.
So I have a set of data.
Let's say the user "Jim" likes the video games with IDs 5, 15, 30, 60, and 25.
Every user in the database gets one row in a table to store information. For example, the row may include separate fields including the user's display name, age, and the date that person was active last.
Now, let's say the website Jim is on is about video games. The website has a list of games that person can say he or she likes to play, in with their own unique ID. What is the is the best way I would store that information and relate that to the user without having to store a list of the game IDs in one field?
Three tables, one being a table of relationships between Games and Users:
Users (UserID, DisplayName, Age, LastActiveDate)
GamesLiked (UserID, GameID)
Games(GameID, GameName, etc)
GamesLiked would have 5 rows for Jim:
UserID GameID
1 5
1 15
1 25
1 30
1 60
I am developing an evaluation system for different programs that needs a lot of flexibility. Each program will have different things to track, so I need to store what data points they want to track, and the corresponding data for the person being evaluated on the particular data point. I am guessing several tables are appropriate. Here is a general outline:
Table: accounts
- unique ID assigned to each account. We'll call this 'aid'
Table: users
- each user with unique ID.
Table: evaluation
- each program will enter in the metrics they want to track into this table (i.e attendance)
- column 'aid' will correspond to 'aid' in account table
Table: evaluation_data
- data (i.e attendance) entered into this database
- column 'aid' will correspond to 'aid' in account table
- column 'uid' will correspond to 'uid' in user table
The input form for evaluation_data will be generated from what's in the evaluation table.
This is the only logical way I can think of doing this. Some of these tables will be growing quite large over time. Is this the most optimal way of doing this?
I'm a little confused about how accounts, users and programs all relate to each other and whether or not account and program are the same thing and that you used the terms interchangeably. I'm going to use different terms which are just easier for me to understand.
Say you have a website that allows freelancers to keep track of different projects and they can create their own data to track. (Hope you see the similarity)
Tables...
freelancers
id title etc
projects
id freelancer_id title description etc
data_options
id freelancer_id title
You can even add other columns like data_type and give options like URL, email, text, date, etc which can be used for validation or to help format the input form.
example data:
1 5 Status
2 5 Budget
3 5 Customer
4 99 Job Type
5 99 Deadline
6 102 Price
7 102 Status
8 102 Due By
This display 3 different freelancers tracking data, freelancers with the id's 5, 99, and 102. Deadline and Due By are essentially the same but freelancers can call these whatever they want.
data_values
id project_id option_id option_value
a column freelancer_id as you would be able to to a join and get the freelancer_id from either the project_id or the option_id
example data:
1000 1 2 $250
1001 1 1 Completed
1002 1 3 Martha Hayes
This is only showing information freelancer with the id 5 has input because option_id's 1-3 belong to that user.
I'm using Access to fill in details in a database across 3 offline computers. This means they all have a copy of the database, do a day of info filling, then get manually uploaded to a central database. Horrid, but it's the only option.
I have a pre-filled database, key identifiers etc are all determined previously; we are adding information to the blank fields for these entries. (Started with 3 key fields, added a few info fields). The user selects an entry and edits it rather than creating one. I then use a script which takes each table and unions the three databases into a table for each. The users do not duplicate work (meaning you don't have Jack working on entry A as well as Jill working on entry A).
My question: How can I get my union query to select all entries, even the unfilled ones, but let the filled ones take precedence? (aka bypass the "duplicate entry" error by choosing the filled in entry instead of the two unfilled entries?)
ex:
JOHN's DB JACK's DB JILL's DB ---> MASTER DB
A: 1, 1, __ 1, 1, __ 1, 1, "Yes" 1, 1, "Yes"
B: 1, 2, "No" 1, 2, __ 1, 2, __ 1, 2, "No"
C: 1, 3, __ 1, 3, __ 1, 3, "No" 1, 3, "No"
Completely terrible way to do this (Unioning offline tables, that is) but we have little other choice due to many other uncontrollable factors.
How about
SELECT Id, Max(Field)
FROM ( Select Id, Field FROM John
Union All ...)
GROUP BY Id