Question: So I'm making a website that allows users to build contact lists. So their are users, the users have lists, and the lists have contacts. It seems to me that I need 3 tables for this but I just want to make sure. 

There would be a User table of course, and then a "List of Lists" table that has the username, and listname, as primary key along with whatever other info we want to attach to the lists as a whole. Finally, for lack of a better word, the List table which would again have the username/listname p.k., then the contact ID and notes and such that the user attaches to that contact on that specific list.

I hope that is a clear explanation. For some reason I feel unsure about this arrangement. For one thing if the website becomes popular the List table could swell to billions of rows. And it also feels a little weird that everybody's list info is all jumbled up in the same table. I suppose I could create separate tables for each user and even for each list but that seems like a bad idea for other reasons.

My db explanation assumes I can use foreign keys on my tables which at the moment isn't actually an option. If I can't get InnoDB tables enabled I will probably use ID's for the lists instead of depending on a compound key. Maybe I should do this anyway?

Answer: 
You do not want to create a table per user. It will be your worst nightmare further down the road. I would have gone for something like this:

```
User Table
----------
User_ID - Integer - Indexed
Username - VarChar[8]
First_Name - VarChar[30]
Last_Name - VarChar[40]

List Table
-----------
List_ID - Integer - Indexed
User_ID - Integer - Indexed
List_Name - VarChar[30]

List_Contact Table
--------------
List_ID - Integer - Indexed
Contact_ID - [whatever data type it is in the existing Contact table]

User.User_ID=List.User_ID
List.List_ID=List_Contact.List_ID
List_Contact.Contact_ID=Contact.Contact_ID [Linking to the existing Contact table]

```

If you build in some caching of the record sets, you won't have much of a performance issue even if you got tons of records in the database. After all, all users won't be on the system at once.

**Edit:** Changed the design to fit the existing Contact table.
That's one way of doing it. You could also have users add contacts and then add tags to their contacts.

Here's what I propose:

**User**  

id  

*other fields*

**Contact**  

id  

fk = User.id  

tags  

notes  

*other fields*

You definitely don't want to start creating new tables for each user, then you'll have thousands/millions of tables and I don't think any DB is designed to be used like that. I'd recommend you get someone who knows more about DB design on your team.