SQL VIEW 是一个全局的逻辑表，可能会或可能不会被持久化。但它仍然是一张桌子。因此，视图是否应该始终遵循第一范式（1NF）？即没有重复的行，只有标量类型，没有从上到下或从左到右的顺序等。更高的范式呢？
对我来说，我的应用程序“消耗”存储过程的结果，我的视图被 SQL 查询“消耗”，这两种用法是互斥的（即我不使用 SQL 查询存储过程的结果集，而我的应用程序不包含 SQL 代码）。我见过其他人使用 VIEW 将一列中的多个值“连接”成一行，通常是逗号分隔的格式。在 SQL 查询中针对这样的列编写谓词需要类似于以下内容：
',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%'
所以在我看来，期望所有可以查询的表只包含标量类型似乎是合理的。我这么想是不是太“纯粹”了？
否 - 我创建视图以匹配我的程序所需的输出。
关系系统的全部意义在于您将数据保存在规范化关系中以提高效率和/或可管理性，然后使用关系运算符将它们转换为您需要的关系。
不存储非物化视图，它是一个查询。
这就是为什么您应该以最适合您的应用程序需求的形式创建它。
有关更多详细信息，请参阅此答案。
确保您的视图至少标准化为 1NF 是非常有意义的。例如，允许重复的缺点是视图的含义模糊不清，并且信息可能被用户错误识别。如果基于此类歧义更新表，则可能会出现不正确的数据。
EFCodd 并不一定同意。在他的 RM 版本 2 书中，他建议允许没有键的视图 - 我认为这是一个大错误。Codd 的视图实际上不允许重复，但它们确实允许每一列都可以为空，因此没有键并且不在 1NF 中。
包含逗号分隔列表的字符串值本身并不违反 1NF。字符串值与任何其他值一样是标量，无论它包含什么。大多数 SQL DBMS 不允许多值属性。
我不认为这是规则，但如果是 - 不应该始终遵循规则。
根据 Chris Date 的说法，视图应该完全标准化：
选择哪些关系作为基础关系以及哪些观点是任意的。举个简单的例子，您可能有员工，并且您可能有一个包含所有员工的基本关系，并且您可能将东海岸员工和西海岸员工作为两个视图。或者您可能将东海岸和西海岸员工作为两个基本关系，并将它们的联合作为一个视图。这完全是任意的。
DBMS 采访 Chris Date - 1994 年 10 月
一个视图（除非它是物化/索引视图）只不过是一个存储的查询视图可以包含多个表，可以对同一个表进行自连接等
否 - 规范化规则适用于数据的持久性，而不是数据的呈现。例如，视图中的任何重复行都会破坏 1NF，这显然过于严格。
有关详细信息，请参阅第一范式。