1

在工作中，正在查看包含三列的表：

  1. 行 ID（非空，整数）
  2. 上下文 ID（非空，整数）
  3. 值（非空，可变字符）

总行数很少（少于 100）。如果没有 Context Id，则 Context Id 当前设置为 0。上下文 ID 是可选的。

主键是 (Row Id,Context Id)

在这种情况下，提出了两种选择：

  1. 保持原样

  2. 将表分成两个表。Context Id 为 0 时的一张表（Row Id，Value）和 Context Id 有值时的一张表（Row Id，Context Id，Value）。

如果有大量行，那么我同意拆分表的决定。如果行数很少，那么分割表格似乎有点过分了。

我会很感兴趣人们在这种情况下推荐什么？总是把一张桌子分成两张桌子更好吗？

谢谢，

-拉里

4

2 回答 2

2

首先，如果这是实体-属性-值反模式，请避免这种情况。这个答案的其余部分假设它不是。

在决定是否要对某事物进行通用建模（单个表）或具体建模（两个表）时，您需要考虑您的代码是否能够通用处理事物或需要特殊情况。

是否需要特殊情况？

您的代码是否会对 ContextId 为 0 进行特殊处理？例如，您是否可以运行一个选择WHERE ContextId=0然后继续以通用方式查看不同的上下文？是否有您只会使用的特殊逻辑ContextId=0？您是否觉得需要在代码中使用一个特殊的常量来表示这个 contextId？你会在一些if陈述中出现这个常数吗？

如果这些问题的答案通常是肯定的，则创建单独的表。如果你以不同的方式对待它，你将不会从把这些东西放在一个表中获得好处。

根据您的问题，我猜这是这种情况。

还是都是通用的？

如果 ContextId 为零的处理方式与整个代码中的所有其他上下文 id 一样，那么请务必将其与其他上下文 id 放在同一个表中。

权衡取舍

如果事情不是那么明确，您需要做出权衡决定。您需要根据您对这些信息的使用有多少是通用的以及有多少是特定的来进行此操作。我会偏向于创建两个表。

于 2013-07-06T04:29:47.743 回答
1

没有足够的信息来决定，但是：
从数据库设计的角度来看minimum side-effect changes，我更喜欢在表中添加一个新列，称为andID列。 (Row Id + Context id) 背后的逻辑是您的应用程序逻辑，应用程序逻辑绑定到更改。 建议使用与业务标识符和逻辑分开的表的主键。任何向最终用户显示的字段都有被要求更改、维护和开发困难的风险。 希望有所帮助。setting it as the Primary Key of the tablehaving a new unique key on (Row Id + Context Id)


于 2013-07-06T06:01:50.297 回答