MySql multiple tables vs single table: performance

Question

Imagine the following categories: bars, places to eat, shops, etc...

Each of these categories will have some common fields, such as

id, name, address and geolocation (Lat and Lng position).  

I am strongly in doubt whether I should create one table that combines these different categories, or whether I should split it up into separate tables (1 table per category).

My thought is that retrieving places based on category and geolocation for each category table separately would be faster in both retrieval and update, certainly when the number of places per category increases.

From this approach, I would go for 1 table per category.

BUT there is a supplementary requirement. Every place will have an owner (user), and one user could own multiple places. So this means that I would either:

• Need a many-to-many table that connects the user table with the central giant table;
• Need one many-to-many table for each of the categories.

Second BUT the situation is, that when the user logs in, all places that this user owns will be returned from a single query, ie. the id + name, assuming that a user could be the owner of multiple places.
From this point of view, the second option seems a very bad idea, because it appears that I would need to create queries to scan through each of the tables.
I realize that I can use indexes to speed up long table scans, yet I am still uncertain about the performance when the number of places would increase dramatically, and there are currently about 8 different categories.

What do you consider the most optimal solution, based on the options that I proposed (or do you see a better option I'm missing out on?).
I should point out that the web application will not often mix up categories, although bars will be able to create events as well.

The answer to this question is invaluable to me, because it will define the fundaments for the further development of my application.
Let me know if anything in my question is not clear to you.

Thank you.

Answer 1

When the data is that similar, a single table is usually best. Consider also that in the future you may add a new category - it would be much easier to just update a category field to include the new category than build a new table, new queries, and modify all the existing code.

As far as speed goes, indexes will make it irrelevant. Add a category field, index it, and speed won't be an issue.