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。如果它是一个平面表，这不会是一个问题，但是要告诉哪些字段属于哪个工具会更难。

字段应出现在基表中的时间是它们在所有工具中的通用时间。

我个人喜欢我的数据库结构来反映业务。感觉更自我记录imo。

Answer 2

如果你有大量的额外字段，那么将它们划分为一种自然分区是有意义的。否则，就数据库而言，我认为这种方式或其他方式并不重要。

从纯粹的架构角度来看，通过一些内在的逻辑分组而不是应用程序来打破字段也可能更有意义。例如LocationItInfrastructure和LocationBuildingOperations或者某些而不是LocationApp1和LocaationApp2。

总的来说，我认为无论哪种方法对您来说最有意义，并且最容易与您合作将是最佳解决方案。

Answer 3

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

例如，您希望显示SERVERNAME = HPSERVER3和LOCATIONNAME = RENO以及您的事务表的所有行，如果HPSERVER3有很多行且RENO也有很多行，则查询计划程序可能会执行嵌套连接和查询会很慢。索引将有所帮助，但与将所有列组合到一个表中相比，设置起来比较棘手。

SQL表设计辅助

3 个答案: