我是数据库的新手，但一直在研究技术，但对于我的数据库的最佳计划却不太清楚？
我有一个'index_table'，其中包含以下列（约65,000行）
dbo.index_table
Line
Locality
Route (unique)
然后，我计划了大约65,000个表，其中包含以下列:(每个表约有20-40行）
dbo.table2,3.4....etc
Route
Place
Name
Stop
我的C＃Web服务，在index_table中找到行和位置之间的匹配，结果将是Route。 然后我需要返回其他表中的所有匹配行。 基本上每个表（除了index_table）都包含一个传输路径上的停靠点，所以我从路径标识符中找到了停靠点。
这是设计的正确方法吗？或者我应该采用不同的方式来简化和提高性能。
我是初学者，请保持温柔：）
答案 0 :(得分：3)
我认为绝对不需要65,000张桌子。您应该阅读database normalization以了解有关拥有高效且有组织的架构的原则。你会更加努力地尝试实施和管理65,000个表格。可以非常有效地管理具有（65000 * 20-40）1300000-2600000行的单个表。
在index_table上，当您的意思是route时，您的意思是单个值吗？或者此route中是否包含多个值？
我对设计的想法是：
路线（路线，线路，地点）
route_stop （路线，地点，名称，停止）
route_stop.route将成为route.route route_stop上的主键可能是构成唯一值的列的组合答案 1 :(得分：1)
拥有65,000条路线，每条路线有20-40个站点，您的数据非常少，而且远远超出了数据库在巨型桌子的重压下死亡的程度。 （如果你有数千万次停止，你仍然可以使用1-3个表，如果需要，可以使用分区或分片和其他技术。）
njk是正确的，因为如果你是路线和站点之间的一对多，你只需要一张路由表和一张停靠表（+1给他BTW）。
但是我无法想象你这里有一个一对多场景。在我所知道的所有传输系统中，路由之间共享停靠点，并且您将拥有多对多方案。我将为停止表引入一个主键stop_id，然后有一个链接路由和停止的连接表。连接表将包含路径中停靠点位置的第三列。
所以在关系数据库中：三个表。
ROUTE: route_id, line, locality
STOP: stop_id, name, place
ROUTE_STOP: route_id, stop_id, position
（旁白：如果您对NoSQL感兴趣，这对于您熟悉文档数据库（例如MongoDB）来说是一个非常好的应用程序。然后您可以使用每个停靠点的列表而不需要位置编号如果我理解正确的话，在一条路线中订购停靠点 - 其中，顺便说一句，我是“温柔的”:) :)您似乎缺少原始问题....）