SQL VIEW应该始终在1NF吗？

Question

SQL VIEW是一个全局逻辑表，可以保留也可以不保留。但它仍然是一张桌子。因此，VIEW应该始终遵循第一范式（1NF）吗？即没有重复的行，只有标量类型，没有从上到下或从左到右的顺序等等。更高的正常形式怎么样？

对我来说，我的应用程序'消耗'存储过程的结果，我的VIEW被SQL查询'消耗'，并且这两个用法是互斥的（即我不使用SQL和我查询存储过程的结果集）应用程序不包含SQL代码）。我见过其他人使用VIEW将列中的多个值“连接”成一行，通常是逗号分隔格式。在针对此类列的SQL查询中编写谓词需要类似于以下的kludges：

',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%'

因此，我认为可以查询的所有表只包含标量类型似乎是合理的。想到这个，我是不是太“纯粹”了？

Answer 1

否 - 我创建视图以匹配我的程序所需的输出。

Answer 2

关系系统的关键在于，您将数据保存在规范化关系中以提高效率和/或可管理性，然后使用关系运算符将它们转换为您需要的关系。

未存储非物化视图，这是一个查询。

这就是为什么你应该以最适合你的应用需求的形式创建它。

有关详细信息，请参阅this answer。

Answer 3

确保您的观点规范化至少1NF非常有意义。例如，允许重复的缺点在于视图的含义不明确并且用户可能错误地识别信息。如果基于这种歧义更新表，则可能会出现不正确的数据。

但是，E.F.Codd并不一定同意。在他的RM第2版书中，他建议允许没有键的视图 - 这是我认为的一个大错误。 Codd的观点实际上并不允许重复，但它们确实允许每一列都可以为空，因此没有密钥且不在1NF中。

包含逗号分隔列表的字符串值本身并不违反1NF。字符串值是任何其他值的标量，无论它包含什么。大多数SQL DBMS不允许多值属性。

Answer 4

我不认为这是一条规则，但如果是这样的话 - 不应该遵循总是的规则。

Answer 5

根据Chris Date的观点，观点应该完全正常化：

  

选择哪些关系作为基本关系，以及哪些视图是任意的。作为一个简单的例子，您可能有员工，并且您可能拥有包含所有员工的基本关系，并且您可能将东海岸员工和西海岸员工视为两个视图。或者你可能将东海岸和西海岸雇员作为两个基本关系，并将所有这些关系的联合作为一种观点。这完全是武断的。

DBMS采访Chris Date - 1994年10月

Answer 6

视图（除非它是具体化/索引视图）只是存储的查询 视图可以包含多个表，可以自己连接到同一个表等等

Answer 7

否 - 规范化规则适用于数据的持久性，而不是数据的表示。例如，视图中的任何重复行都会破坏1NF，这显然过于严格。

有关详细信息，请参阅First normal form。