Is it good practice to automatically create tables in a database when a user registers?

I'm making my first site with Django, and I'm having a database design problem.

I need to store some of the users history, and I don't know whether it's better to create a table like this for each user every time one signs up:

table: $USERNAME$

id  |  some_data  |  some_more  |  even_more

or have one massive table from the start, with everyone's data in:

table: user_history

id  |  username  |  some_data  |  some_more  |  even_more

I know how to do the second one, just declare it in my Django models. If I should do t开发者_如何学JAVAhe first one, how can I in Django?

The first one organises the data more hierarchically but could potentially create a lot of tables depending on the popularity of the service (is this a bad thing?)

The second one seems to more suit Django's design philosophies (from what I've seen so far), and would be easier to run comparative searches between users, but could get huge (number of users * average items in history). Can MySQL handle, say, 1 billion records? (I won't get that, but it's good to plan ahead)

Definitely the second format is the way you want to go. MySQL is pretty good at handling large numbers of rows (assuming they're indexed and cached as appropriate, of course). For example, all versions of all pages on Wikipedia are stored on one table in their database, and that works absolutely fine.

I just don't know what Django is, but I'm sure it's not a good practice to create a table per user for logging, (or almost anything, for that matter).

Best regards.

You should definitely store all users in one table, one row per user. It's the only way you can filter out data using a WHERE clause. And I'm not sure if MySQL can handle 1 billion records, but I've never found the records limit as a limiting factor. I wouldn't worry about the records limit for now.

You see, every high-loaded project started with something that was just well-designed. Well designed system has better perspectives of being improved to handle huge loads.

Also keep in mind, that even genious guys in twitter/fb/etc did not know what issues they will experience after a while. And you will not know either. Solving loading/scalability challenges and their prediction is a sort of rocket-science.

So the best you can do now - is just starting with the most normalized db and academic solutions, and solve the bottlenecks as soon as they will appear.

When creating a relational database, you would only want to create a new table if it contains significantly different data than the original table. In this case, all of the tables will be pretty much the same, so you would only want 1 table for all users.

If you want to break it down even further, you may not want to store all the users actions in the user table. You may want to have 1 table for user information, and another for user history, ie:

table: User
Id | UserName | Password | other data

table: User_history
Id | some_data | timestamp

There's no need to be worried about the speed of your database as long as you define proper indexes on the fields you plan to search. Using those indexes will definitely speed up your response time as more records are put into your table. The database I work on has several tables with 30,000,000+ records and there's no slow-down.

Definitely DO NOT create a TABLE per user. Create a row per user, and possibly a row per user and smaller tables if some data can be factored.

definitely stick with one table for all users, consider complicated queries that may request extra resources for running on multiple tables instead of just one. run some tests, regarding resources i am sure you will find out one table works best.

Everyone has pointed out that the second option is the way to go, I'll add my +1 to that.

About the first option, in Django, you create tables by declaring subclasses of django.models.Model and then when you run the management command syncdb it will look at all the models and create missing tables for all "managed" models. It might be possible to invoke this behavior at run time, but it isn't the way things are done.