The main pieces of data I'm having my users enter is an object called an "activity" which consists of a few text fields, a few strings, etc. One of the text fields, called a "Description", could possibly be quite long (such as a long blog post). For each user I would like to store all of their activity objects in a mysql database.
Here are some solutions I've thought of:
Have a separate mysql table for each user's activities, i.e. activities_userX, X ranging over
Use json to encode these objects into strings and store them as a column in the main table
Have one separate table for all these activities objects, and just index them; then for each user in the main table have a list of indices corresponding to which activities are theirs.
What are the pros/cons of these methods? More importantly, what else could I be doing?
Thanks.
Have a separate mysql table for each user's activities, i.e. activities_userX, X ranging over
A table for every user? That just means an insane number of tables.
Use json to encode these objects into strings and store them as a column in the main table
JSON is a good transport language. You have a database for storing your data, use its features.
Have one separate table for all these activities objects, and just index them; then for each user in the main table have a list of indices corresponding to which activities are theirs.
Getting closer.
This sort of relationship is usually known as 'has many'. In this case "A user has many activities".
You should have a table of users and a table of activities.
One of the columns of the activities table should be a foreign key that points to the primary key of the user table.
Then you will be able to do:
SELECT fields, i, want from activities WHERE userid=?
Or
SELECT users.foo, users.bar, activities.description from users,activities
WHERE user.userid=activities.userid
Related
I'm new to MySQL and databases, and this question is more about best practices than exact code.
If I want to create a database that let's users register an "account" so they are then able to access and track the value of virtual goods in a video game, including selecting items from a list and marking them (thus requiring the choices to be associated with their account), Is it better to store the users choices in the same table that holds their username/account-info? Or should the information be stored in a separate table with a reference to the associated account?
Or should I create a table for each user, instead of having one for registration/account info, and another for data, etc.?
Does the best practice for this vary with the expected number of users and/or amount of data?
Is there a way to set it up that allows for handling growth from 2 or 3 users to hundreds?
The answer is to create one table for accounts, one table with choices that are referenced to that account with some type of token.
There's no reason to create a new table for each user. You should have one table, and differentiate between the users using the data in the table (e.g., the userid, the username, etc).
I wanted to ask for some advice in structuring the SQL database I am creating.
UPDATE: Storing Data in MySQL as JSON seems to clearly indicate that storing JSON in MySQL is not a smart choice.
My initial idea was to create a table for each user named '{user_id}' with the following rows:
Datetime
Entry (one-digit int)
Comment (reasonably short string)
Activity (one word)
However, I have read that creating a table for each user is not advisable because it's unmanageable in the long run.
Specifically, I wanted to know how I could put all the information that I would have put in the '{user_id}' table in the user's row of my 'members' table.
I had a few ideas, but don't know how good they are:
Storing the user data as a JSON object (converted to a string) in an additional column 'data' of the 'members' table. Would that become unmanageable in the long run too (due to JSON object string becoming too long)?
Storing the user data in various additional columns of the 'members' table, maybe one for each of the parameters listed above (each of them being an array)
Storing the user data in various additional columns of the 'members' table, maybe one for each of the parameters listed above (each of them being a dictionary or some other data structure)
Are there any other better ways, or better data storage types than JSON objects?
What would be a good way of storing this information? Isn't handling the arrays/dictionaries going to become unmanageable over time when they become very big?
(one thing to keep in mind is that the 'data' entries would have to be daily modified and easily accessed)
I think you may simply want a single additional table, maybe called "activities" with a foreign key "user" to the "members" table.
Then for each row in each of the per user table that you were originally thinking of, you have a row in the activities table with the value of "user" being the user in question. Since each row is of relatively small bounded size, one would expect the database to handle it well, and efficiency issues can be addressed by indexing. Basically I am agreeing with #MikeNakis
I'm running on a version of MySQL that does not support foreign key relationships.
Suppose I have two tables, one holds a number of users while the other one holds a number of topics. I want each of the topics to have a field which holds a set of user id's who participated in that topic. I read the type SET's documentation and it says it must be values from predefined values. So how should I go about doing this?
You don't want an extra field, this is a very inefficient way of storing such things. You want a new table.
In your third table (called, say, topicUsers). you would have just two fields: userId and topicId. Then you can look at this table and join data from the others as needed.
This is called normalisation
I'm building an application that will have two different types of users, lets call one User_type_a and the other User_type_b. I'm wondering if I should create 1 table in my database for both types of users and have a property distinguishing what type of user each record is, or if I should create two separate tables for each type of user.
Considerations:
1. 99% of all users will be User_type_a
2. User_type_b will require properties in addition to User_type_a (such as credit card #'s, etc)
Which design approach is optimal? Or does it not really matter.
One table for users, assuming that user type b are real users. Create another table that links to the user table to store the CC details for user type B.
This allows you do do all major user changes easily (searching users, changing user details, looking up users for login, etc), but doesn't contain many wasted columns.
Note that if you are storing credit card numbers, your datacenter and architecture will have to be PCI compliant, which is expensive.
If type B has only additional information (columns) to the generic user type then use:
If types A and B have some common columns and a set of distinct columns for each one, then use
I both cases keep all common columns in the User table -- sub-type tables have only columns specific to each one. Note that UserID propagates to sub-type tables.
The best way to do this would be to store all users in the same table, and have a foreign key relating to a second table, which contains the extra information.
**USER TABLE**
NAME AGE TYPE FK
Grant 25 Adult 1
Susan 4 Child null
John 65 Adult 2
**EXTRA TABLE**
FK CREDITCARD OTHER
1 234234... blah
2 2334... blah
This would be more efficient with space.
So it sounds like User_type_a and User_type_b are both identical in terms of data, with the exception being that User_type_b has additional data above and beyond User_type_a (but User_type_a does not have any unique data like this).
Given this, I would create a single users table that stores the User_type_a data (i.e. the intersection of the two user types). Then create a second table for the additional User_type_b data, with a foreign key linking that one back to users. (Note that there is no column here in the users table defining which users are which type.)
How to tell the difference between the two user types? Simple: User_type_b has a related row in the second table; User_type_a does not. This makes it easy for any application functions that don't care about the difference to just get the common user data for everyone, while functions that need the extra User_type_b data (or otherwise only care about one type or the other) can still determine who is what type and get that extra data.
Use one table. They are both users. Your code will have more general use between both types so you will avoid having to do 2 sql queries when dealing with users (even though they are not relevant 99% of the time)
I'm creating a social networking site with features similar to Facebook.
I want to start with schema design for my database.
What i thought was to create each table for each user who registers to our site.. am i doing right?
If a million users register to my site, a million tables will be created. how to go on about optimizing this? Please do suggest me techniques to overcome this and some references or books to learn about such concepts will be vry useful..
Thanks in Advance.
This is not the way you want to do it.
What you want to do is have a table (perhaps called 'users') that contains one row for each user that registers. Creating a new table for each user is completely pointless and would cause terrible performance.
Maybe something like this:
TABLE users
- username AS VARCHAR(255)
- password AS VARCHAR(255) (use a hashed password, of course)
- ...
Then when a user registers, simply insert the information they provide into the users table as a new row.
That would be massive overkill. You should probably read up on database design (start with normalisation, but don't overdo it). Then write down what you want to save for each user, and think about how to save it without saving data double.
But I'm pretty sure a table-per-user is not an option for this.
You must be confusing the meaning of the words database, table, field (or column), record (or row).
A database contains all your data for a specific project. There is always one database per project (or almost always)
A table contains all data of a specific entity and by saying entity, I mean an object type that is imaginable as real or seperatelly existing by itself. A person is an entity, a book is an entity, a phone is an entity, a movie is an entity, etc. Each of these would be seperate tables in a database.
A field (or column) is a data type that represents a specific characteristic (feature) of a table's entity. For example a table of users can have the fields: NAME, SURNAME, AGE, etc. These are all features that a user has.
A record (or row) is an actual item of one table. It is a single 'piece' of the table's entity. For example in a table of users, one record is one single user, namely {NAME:"John", SURNAME:"Smith", AGE:"32"}.
In your example, I can tell you for sure that you only need one database. You want to store information for many users, so you need one table called USER. You will need to store features to your users, like: name, surname, age, address, etc., then you will need to create the respective fields in this table: NAME, SURNAME, AGE, ADDRESS, etc. Then you will need to insert your data in the database as records. It will be one record per user you want to store.