Should you create a table for each user to contain information on specific content for an account, say favorite articles, interests, ect. User defined lists that would be used to generate useful content using a tag system to define groups of content. Would i be approaching this close to right, or is there a better way. i know u should not define more than one thing in a column, but i also would want the fewest number tables too? is there a way to use a table for all users to store info in such a manner?
Ideally your the number of tables in your database should not depend on the number of users. Have a table of for the users and another table for preferences with a foreign key to the users table.
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).
Im thinking about what is the better way to design a database with the following statements:
There are 3 kinds of users (3 differents roles).
They have some common fields, however they have differents fields too.
Solution A:
All user in the same table (some users will have empty fieds depending of their role).
Solution B:
A main table where i will add users and their role. In addition i will create 3 extra tables where i will record with extra fields (depending of the table) and each record will have an id related with the user in the main table.
Solution C: A main table with basic user info, and a second table with the metadata user info where each record means a field of a user. That it's similar than WordPress
Yours is a case of Specialization/Generalization. Since you said User (1, 2, 3) share common properties, it is best to have a General entity - User with all the common attributes.
Then you can Specialize to 3 different types and have the specific attributes to each type.
So, option B is what I think is best solution for your problem.
Option A will cause too many null values and option C is overly complicated.
That depends :-)
Will you ever treat the users the same? E.g. at login time: Will someone just login with a username and this can be any of the three user types? Then you need a user table with a username and a unique index on it. This is solution A or B. I'd prefer B over A, so you can decide which of the fields are nullable for the specific role.
Or will you never deal with a user with an unknown role (such as: a person logs in with a role plus a username, so it suffices to have three different tables each with their own usernames)? This would be three special user tables and no common user table.
Option C would be something easy to implement in order to give users additional attributes, but can become a hassle. Especially when there are obligatory fields and fields that link to other tables (such as a job number that is meant to be the key in the jobs table, but you cannot use a foreign key then). I usually don't take this route, if it is avoidable.
I'm developing an application where in there are 3 different set of users: admin,manager,employee.
I intend to have a single log in page for all users.
based on the credentials different users will be shown different pages.
is this a good idea?
Also how do i go about designing db?
I have created "roles" table with roles_id(primary_key) and role_name
what next
Yes its best to keep everything as simple and uniform as possible. Therefore I would agree that a single login page, irrespective of type of user is a good idea.
Within the table that you store the users details in an additional field that designates what type of user would be adequate. That could be the foreign key to the roles table where you provide detail of what each role can do.
I am using Ruby on Rails 3 and MySQL.
In my project I would like to create an activity-stream "module" in order to save each user action information in a dedicated user table. That is, to create a database table for each user.
Is it a good approach to create a database table for each (new registered) user in my application?
No, it is not a good approach. Why would you create a separate tables with all the same fields? Just add user_id to your table and store all info for every user in there.
I do something similar, and it's not necessary to create a whole table for each user. For example, I have a table called "user_actions", and in it there is a column, "user_id".
The relationships are:
User has_many :user_actions
UserAction belongs_to :user
And you're done. Let the foreign-key relationship that comes naturally take care tying the specific action to a specific user.
Once you do that, you only need to decide:
Which actions cause an entry to be added?
How long should you retain the data (1 week, 6 months)?
For example, on my site, I keep a log of the last 5 things a user viewed, and present that list to them on a section of the page called "Recently viewed items" for convenience.
I also have a separate table called "admin_actions" that I use for security logging that keeps track of everything done under an admin account, and what admin account made what sort of change.
I guess the answer is that it depends on how many users there are. If it's not a small, defined number then I'd suggest that it's not a good idea to create one table per user.
I'd suggest a single table with one column being a unique identifier for the user. Make sure that whenever you're querying the table that you're using an index that has this column as the first column in the key. E.g. PRIMARY KEY(user_id, activity_time)
This should allow for fast and efficient reading of the rows.
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.