SQL表辅助设计

Question

我正在为一个商业集团构建多个基于web的工具。这些工具中的许多都需要一个城市名称的托管列表。现在，每个工具都有自己的位置查找表，我想将其集中起来，以便所有工具都可以使用一个位置表，这样就不需要多次添加位置了。

我创建了主位置表

-----------------------------
| LocationID | LocationName |
-----------------------------
|     1      |     Reno     |
-----------------------------
|     2      |  San Diego   |
-----------------------------

我想添加特定于每个工具的额外字段，但不一定相互关联。我应该创建其他表来管理这些字段，还是只在需要时将新字段添加到此位置表中？

我最初的想法是创建表来保存每个要引用的附加工具的设置。

WebTool1 settings table
    ------------------------------------------------------
    | LocationID | HasAirConditioning|  HasSecurityGuard |
    ------------------------------------------------------
    |     1      |     TRUE          |       TRUE        |
    ------------------------------------------------------
    |     2      |     FALSE         |      TRUE         |
    ------------------------------------------------------

WebTool2 settings table
    -------------------------------------------------------
    | LocationID | ServerName   |  RequiresDriveMapping   |
    -------------------------------------------------------
    |     1      | DELLSERVER1  |       TRUE              |
    -------------------------------------------------------
    |     2      |  HPSERVER3   |      FALSE              |
    -------------------------------------------------------

这是个好策略吗？如果没有，为什么？

Answer 1

我认为这是一个非常好的策略。

对于数据库，我倾向于先正常化后再问问题.很少会遇到性能问题..。在这种情况下，查询语法不会变得更加复杂。

唯一的问题是，您可能需要构造约束，以确保关系保持在1:1。如果是一个平坦的表，这将不是一个问题，但更难区分哪些字段属于哪个工具。

字段应该出现在基表中的时间是所有工具中常见的字段。

我个人喜欢我的数据库结构来反映业务。我觉得更像是在记录海事组织。

Answer 2

如果您有大量这些额外的字段，那么将它们作为一种自然分区进行分割是有意义的。否则，就数据库而言，我认为这样或那样都不重要。

从纯模式的角度来看，用一些内在的逻辑分组而不是应用程序来划分字段也可能更有意义。例如，LocationItInfrastructure和LocationBuildingOperations或somesuch，而不是LocationApp1和LocaationApp2。

总的来说，我认为无论哪种方法对你个人来说最有意义，并且对你来说最容易使用，都是最好的解决方案。

Answer 3

这些桌子有多大？如果表将包含1000或更少的行，则没有问题。但是，如果是100 K或更多，您需要考虑如何查询这些表，因为表连接会变得很慢。

例如，您希望使用SERVERNAME = HPSERVER3和LOCATIONNAME = RENO显示所有行，加上您的事务表，如果HPSERVER3有很多行，而RENO也有很多行，那么查询规划器可能会执行嵌套连接，查询速度也会很慢。索引会有所帮助，但与将所有列合并到一个表中相比，设置要复杂得多。