title: Separating into multiple tables or put them all in one?
body: <p>For self-learning purpose, I'm trying to create a simple web application that creates a TODO list where each list gets a unique URL. I currently use the following database design. The <code>onlinelist.list</code> table stores URL and password of each list. The <code>onlinelist.item</code> stores items stored in each list.</p>
  
  <pre><code>onlinelist.list                   onlinelist.item
  +----+-----+-------------+        +----+---------+-----+
  | ID | URL |  Password   |        | ID | Content | URL |
  +----+-----+-------------+        +----+---------+-----+
  |  1 | abc | rfk49gh34   |        |  1 | apple   | abc |
  |  2 | pqr | 12345       |        |  2 | banana  | xyz |
  |  3 | xyz | password123 |        |  3 | milk    | pqr |
  +----+-----+-------------+        |  4 | beef    | abc |
                                    |  5 | egg     | abc |
                                    |  6 | pasta   | xyz |
                                    |  7 | lemon   | pqr |
                                    |  8 | carrot  | xyz |
                                    +----+---------+-----+
  </code></pre>
  
  <p>It makes me worry to see some URLs repeated in <code>onlinelist.item</code> table. To get all list items for the list stored at "abc", it would need to go through all elements of the table and find those where URL equals "abc". (I'm assuming this is how the SELECT statement works.) Deleting a list item would also need to perform this search.</p>
  
  <p>Shouldn't it more efficient if I create a separate table for each list, i.e. <code>onlinelist.abc</code>, <code>onlinelist.pqr</code>, <code>onlinelist.xyZ</code>, so that the search does not need to look at irrelevant entries? But then, I think that it doesn't really make sense to have tables called <code>onlinelist.abc</code> or <code>onlinelist.xyz</code>. Do I already have a good design?</p>