This isn't much of a coding question as opposed to seeking help on going down the right path. So, I have my users set up with username, password, email, posts, & id. The basic forum stuff. But, if I were to add more, say some games in the website that you play and store data with your forum account (being your account for the whole website, in other words), would it be wiser to add those fields to the existing table (i.e.: game1_money) or make another table for each individual side project, then create and link it to each user upon starting the "game" or whatever it is?
If I'm too vague, tell me and I'll try to clarify.
Use separate tables and then a left join when you want the data for the specific game or application. Then if 10% of the users are signed up for the game you don't waste the table space for the other 90%. You also don't need to keep fiddling with the user table.
Anonymous,
Always try to keep your primary table clean and relate everything back to a unique, individual index. In this case, whether you add games, comments, documents, whatever...user User_ID (for example) as the related index field that points back to your main users table.
Here's a good reference on building normalized tables
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
Don't store that information in the Users table. Normalise into separate tables.
Create a separate table, say GameSavedInfo, to store this information and reference the users ID from the user table.
I would also create a GameDetails table and use its Id in the GameSavedInfo table.
Related
I know that there is not a "good" answer to my question, and it is opinion based. But since I am now learning those things on my own, I need advice.
I have a table on Mysql about "Customer". In this table there are columns referred to customer's info like name, surname, date of birth, address, and so on.
Each customer has his own credentials (username, password).
Now my question is: It is better to keep credentials in "customer" table, or it has sense to create a separate table, in order to guarantee the protection of these credentials, and also keep track of the changes of them along time, without wasting space repeating all the others customers' info?
You need to answer some questions about your data:
Do the columns change? People change names, addresses, and so on.
The credentials will change, at least the password.
What sort of history do you need?
My recommendation would be different sets of tables for different purposes:
One table that defines the customer id and whatever other immutable information there is (perhaps the date of becoming a customer and related information).
One or more tables with PII (personally identifiable information). You want to keep PII separate for regulatory and privacy reasons.
Tables for history. How you do this depends on your data model and what you need. A simple method is a single archive table per table in your data model. However, I might recommend type-2 tables (i.e. those having version effective and end dates).
Separate tables for credentials. These are even more sensitive than PII and you will want to control access.
Remember to never store clear-text passwords. And often you want to keep a history of passwords to prevent users from using the previous one.
It is better to create personal information in the person table and additional customer information in another table that has a relationship with the customer, and if you have any other information about the person in another table and link it to the table of persons.
I am trying to make a database of Users and Movies. Then I want to allow users to click on a movie and mark it as "watched".
What would be the best way to go about structuring this. I mean, could I simply have a table called "Watched" and simply link the UserId to the MovieId in that table to signify that the user has watched that particular movie. This would mean that every instance of a movie being watched will need a record in the table, right? It seems like it could end up taking up ALOT of space in the database.
Is there not an easier way to do this? Sorry if it sounds abit vague. I'm thinking its kind of similar to "friends" on facebook. Would there be a table somewhere where each instance of a friendship occuring is recorded as a record, or is there a way of simply having a list of friends lookup, or something, i don't know... any help much appreciated, thanks!
Your suggestion is correct, using table called "Watched" and simply link the UserId to the MovieId in that table.
In this way, you will have a normalised database, with one-to-many relationship on both sides, toward the "Movies" and "Users" tables.
It will also save you performance cost also when retrieving data later, in case your database becomes a really large one.
You need a user table, movies table, friendship_match table and if you want to record which movie watched at which time, a watch table (with this one you can also display watch history for users)
You have to have a table for friendship because it will contain requests also. If a person adds someone, it doesnt mean the other person will accept it. Other than this, it will take really take a long time if you query the whole users table.
I want to track keywords and have a score system in my database for each user.
I'll have a user table and their website table.
user table will have basics of user id, email, password, etc
website table will have id, user_id, keywords, and score.
So I will keep all their keywords (max 5 keywords) in a website table implementing the MySQLicious tagging solution.
The question I have is, I will be constantly updating the score so should I also keep the "score" field in website table or create a brand new table and link all the scores based on website's id field??
edit: also should I keep the keywords in the same table or separate them?
If all you have is a score, it is best to add it to the website table. In most cases, making a separate table complicates things while offering little advantage. However, there are some cases in which you may want to make a separate table:
You have many many websites and only some of them have a score. Instead of storing NULL scores for most websites, you add a separate table that only stores scores for websites that have them.
The website and scores do not have a one-on-one relation, or that relation has properties on its own (not likely in your scenario).
You have a lot of websites already and are now adding the score functionality. You maybe don't want to change the database schema because that takes a long time when deploying the new version of your app. Instead of changing the website table, which may take a long time, you add a new table.
Just keep score in the same table. There is no benefit if you keep it in a separate table. If you want to update you can directly update the table with the new score there is no other benefit if you separate those table, except some burden of foreign keys.
I know this question has been asked and answered many times, and I've spent a decent amount of time reading through the following questions:
Database table structure for user settings
How to handle a few dozen flags in a database
Storing flags in a DB
How many database table columns are too many?
How many columns is too many columns?
The problem is that there seem to be a somewhat even distribution of supporters for a few classes of solutions:
Stick user settings in a single table as long as it's normalized
Split it into two tables that are 1 to 1, for example "users" and "user_settings"
Generalize it with some sort of key-value system
Stick setting flags in bitfield or other serialized form
So at the risk of asking a duplicate question, I'd like to describe my specific scenario, and hopefully get a more specific answer.
Currently my site has a single user table in mysql, with around 10-15 columns(id, name, email, password...)
I'd like to add a set of per-user settings for whether to send email alerts for different types of events (notify_if_user_follows_me, notify_if_user_messages_me, notify_when_friend_posts_new_stuff...)
I anticipate that in the future I'd be infrequently adding one off per-user settings which are mostly 1 to 1 with users.
I'm leaning towards creating a second user_settings table and stick "non-essential" information such as email notification settings there, for the sake of keeping the main user table more readable, but is very curious to hear what expects have to say.
Seems that your dilemma is to vertically partition the user table or not. You may want to read this SO Q/A too.
i'm gonna cast my vote for adding two tables... (some sota key-value system)
it is preferable (to me) to add data instead of columns... so,
add a new table that links users to settings, then add a table for the settings...
these things: notify_if_user_follows_me, notify_if_user_messages_me, notify_when_friend_posts_new_stuff. would then become row insertions with an id, and you can reference them at any time and extend them as needed without changing the schema.
I am doing the design of a database, that will have eventually thousands of users. Each user has your profile and specific data associated.
In your opinion, it is best practice a table for id, username, activationLink and hash and another for address, age, photo, job, or it is best a unique table for all stuff?
thanks for your time
If:
All (or almost all) users have all data filled
Most of the time you query for all fields
then keep them in a single table, otherwies split them.
In your model, activationLink seems to be queried for only once per activation, so I'd move it into a separate table (which would allow deleting it after the account had been activated).
Address, age, photo and job are usually shown along with the username, so it would be better to merge them into a single table.
Don't allow your initial design to limit the ability (or just make it difficult) to expand your requirements in the future.
At the moment, a user may have one address so you might put it in the users table - what if you want them to be able to store "work" and "home" addresses in future, or a history of past addresses?
A user may only be allowed to have a single photo, but if you put it (or a URL for it) in users.photo, then you'd have to change your data structure to allow a user to have a history of profile photos
As Quassnoi mentions, there are performance implications for each of these decisions - more tables means more complexity, and more potential for slow queries. Don't create new tables for the sake of it, but consider your data model carefully as it quickly becomes very hard to change it.
Any values that are a strict 1-to-1 relationship with a user entity, and are unlikely to ever change and require a history for (date of birth is a good example) should go in the table with the core definition. Any potential 1-to-many relationships (even if they aren't right now) are good candidates for their own tables.