想象一下下面的类别：酒吧、吃饭的地方、商店等…
每个类别都有一些公共字段，例如
id, name, address and geolocation (Lat and Lng position).
我非常怀疑是否应该创建一个表来组合这些不同的类别，或者是否应该将其拆分为单独的表（每个类别一个表）。
我的想法是，基于类别和地理位置分别为每个类别表检索位置在检索和更新方面都会更快，当然，当每个类别的位置数增加时。
根据这种方法，我将为每个类别指定一个表。
但有一个补充要求。每个地方都有一个所有者（用户），一个用户可以拥有多个地方。所以这意味着我要么：
需要一个连接用户表和中央巨表的多对多表；
每个类别需要一个多对多表。
第二种情况是，当用户登录时，该用户拥有的所有位置都将从一个查询返回，即id+名称，假设一个用户可能拥有多个位置。
从这个角度来看，第二个选项似乎是一个非常糟糕的主意，因为看起来我需要创建查询来扫描每个表。
我意识到我可以使用索引来加速长表扫描，但是我仍然不确定当位置数量急剧增加时的性能，目前大约有8个不同的类别。
根据我提出的方案，你认为最理想的解决方案是什么（或者你认为我错过了一个更好的方案？）.
我应该指出的是，web应用程序不会经常混淆类别，尽管bar也可以创建事件。
这个问题的答案对我来说是非常宝贵的，因为它将为我的应用程序的进一步开发定义基础。
如果你对我的问题不清楚，请告诉我。
谢谢您。
最佳答案
当数据如此相似时，一个表通常是最好的。还可以考虑在将来添加新的类别——只需更新一个类别字段就可以包含新的类别，而不是构建一个新的表、新的查询和修改所有现有的代码。
就速度而言，索引将使其变得无关紧要。添加一个category字段，索引它，速度就不成问题了。