To answer the titular question: No - It really doesn't matter. Fill the table however you like. Choose a good column/columns to index by, but the indexer will build its own model-list of the values that do make sense in terms of ordering, but is completely unrelated to the order/granularity with which you inserted it. Should the data of equal structure be in one table rather than two? - yes definitely. This is very important. You can imagine this problem yourself by arm-chair experiment: If I told you to look up someone's phone number in an old-school phonebook, the book is ordered by Surname, Name. It matters very little that the phone numbers themselves, or their addresses or such are unordered or not clumped together, you are only going to be looking up a Surname+name. Similarly - would you like to do one lookup in a nice fat phonebook, or two different look-ups in two thinner phonebooks? The former is always preferred, even by humans, but especially so by computers. Mathematically, [a binary search](https://en.wikipedia.org/wiki/Binary_search_algorithm) (SQL engines typically use [B-Trees](https://en.wikipedia.org/wiki/B-tree) and not straight binary look-ups per sé, but they still allow look-ups in logarithmic time) requires a maximum 24 steps to search through ~1 million records, and 25 steps to search ~2 million records. 25 steps is a lot better than doing 24 steps through a million and again 24 through the million in the next table. To be more direct: You can extrapolate it out to say, 10 million records in 10 tables, which takes 10 x 24 steps (240 steps[1]) each to search, and 10 million records in one single table which can be searched in a grand total of 28 steps. It is clear that the optimal always converges on the single table. There are other more human advantages too, not having to join tables to get a single result set, Understanding your own data and schemata better, etc. [1] Note that it doesn't always take the full 24 steps, sometimes luck lets us hit the desired item in less steps - BUT, this average converges near the final steps and not the initials, so that in a 24-step look-up (~million rows) if we do a few million look-ups and count the steps each time, the average goes to somewhere around the 23 steps mark and not 12 steps. Cardinality will influence this average greatly, but can be ignored for Unique/Primary keys. [B-Trees](https://en.wikipedia.org/wiki/B-tree) are slightly less efficient at the steps, but it is paid in service of much more efficient storage.