is having millions of tables and millions of rows within them a common practice in MySQL database design?

Question

I am doing database design for an upcoming web app, and I was wondering from anybody profusely using mysql in their current web apps if this sort of design is efficient for a web app for lets say 80,000 users.

1 DB

in DB, millions of tables for features for each user, and within each table, potentially millions of rows.

While this design is very dynamic and scales nicely, I was wondering two things.

1. Is this a common design in web applications today?
2. How would this perform, time wise, if querying millions of rows.
3. How does a DB perform if it contains MILLIONS of tables? (again, time wise, and is this even possible?)
4. if it performs well under above conditions, how could it perform under strenuous load, if all 80,000 users accessed the DB 20-30 times each for 10 -15 minute sessions every day?
5. how much server space would this require, very generally speaking (reiterating, millions of tables each containing potentially millions of rows with 10-15 columns filled with text)

Any help is appreciated.

Answer 1

1 - Definitely not. Almost anyone you ask will tell you millions of tables is a terrible idea.

2 - Millions of ROWS is common, so just fine.

3 - Probably terribly, especially if the queries are written by someone who thinks it's OK to have millions of tables. That tells me this is someone who doesn't understand databases very well.

4 - See #3

5 - Impossible to tell. You will have a lot of extra overhead from the extra tables as they all need extra metadata. Space needed will depend on indexes and how wide the tables are, along with a lot of other factors.

In short, this is a very very very seriously bad idea and you should not do it.