SQL VIEW是一個全局的邏輯表，可能會或可能不會持久化。但它仍然是一張桌子。因此，VIEW應該始終遵循第一範式（1NF）嗎？即沒有重複的行，只有標量類型，沒有從上到下或從左到右的順序等。那麼更高的標準形式呢？對我來說，我的應用程序'消費'了存儲過程的結果，我的VIEW被SQL消費'消費'，並且這兩種用法是相互排斥的（即，我不查詢使用SQL的存儲過程的結果集和我的應用程序不包含SQL代碼）。我已經看到其他人使用VIEW將一列中的多個值連接成一行，通常以逗號分隔的格式。寫作對這樣的列的SQL查詢謂詞需要一個類似的組裝機：SQL VIEW應該總是在1NF中嗎？
',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%'
所以在我看來，合理的預期是可以查詢到僅由標量類型的所有表。我是否過於「純粹」思考？
確保您的視圖標準化爲至少1NF是非常有意義的。例如，允許重複的情況具有這樣的缺點，即視圖的含義不明確，並且用戶可能錯誤地識別信息。如果基於這種模糊性更新表，則可能會發生不正確的數據。
E.F.Codd雖然不一定同意。在他的RM版本2書中，他建議允許沒有鑰匙的觀點 - 我認爲是一個很大的錯誤。 Codd的觀點實際上不允許重複，但他們確實允許每列都是可空的，因此沒有密鑰並且不在1NF中。
包含逗號分隔列表的字符串值本身並不違反1NF。字符串值是任何其他值的標量，無論它包含什麼。大多數SQL DBMS不允許多值屬性。
否 - 我創建視圖以匹配我的程序需要的輸出。
關係型系統的關鍵在於您將數據保存在規範化關係中以提高效率和/或可管理性，然後使用關係運算符將它們轉換爲您所需的關係。
未存儲非物化視圖，它是查詢。
這就是爲什麼你應該以最適合你的應用需求的形式來創建它。
有關更多詳細信息，請參見this answer。
我不認爲這是一個規則，但如果是 - 沒有規則應該總是被跟着。
我認爲接受的方法是你遵循標準化的'規則'，然後你遵循非規範化的'規則'，如果有足夠的理由這樣做的話。除非你是一個無政府主義者，在這種情況下，這些規則是沒有規則的，你可以對抗權力，束縛褲子和榮譽。 – onedaywhen 2009-06-26 14:03:37
視圖（除非它被物化/索引視圖）不過是一個存儲的查詢 視圖可以包含多個表，可以自行加入到同一個表等等等等
事實上，我可以將查看的表（a.k.a. VIEW）加入到其他表中......因此，如果所有列都是標量類型，那麼確實會有所幫助。 – onedaywhen 2009-06-26 13:41:54
否 - 規範化規則適用於數據的持久性，而不是它的表現。例如，視圖中的任何重複行都會打破1NF，這顯然過於嚴格。請參閱First normal form。
據克里斯日期，觀點應該是完全規範化：
爲你做這關係基礎的，並且該視圖的選擇，是任意的。作爲一個微不足道的例子，你可能有員工，你可能有一個包含所有員工的基礎關係，你可能有東海岸員工和西海岸員工作爲兩個視圖。或者你可能把東海岸和西海岸的僱員作爲兩個基本關係，並且推導出所有這些人的聯合。這完全是任意的。
與克里斯日期DBMS專訪 - 1994年10月
我的觀點僅由SQL查詢 '消費'。如果我的程序需要「特殊」格式的結果集，那麼我會在存儲過程或中間層中執行此操作。我並不是建議每個存儲過程的輸出都應該在1NF中，只有*表格形式的輸出（我猜那樣會包括適用的表格變量）。 – onedaywhen 2009-06-26 14:11:52
您明顯爲您自己的應用程序創建了規則（例如客戶端沒有SQL），這些規則適用於您。它們更具限制性，我認爲是最佳實踐，但限制性太強的好處在於，以後改變主意總是很容易的，而且會變得更加輕鬆 - 不容易走另一條路。但通常情況下，視圖的輸出可能違反1NF（雖然dupe行無用，AFAIK）。事實上，使用醜陋的視圖是將醜陋的設計遷移到乾淨設計的最佳方式之一 - 您需要視圖來支持傳統客戶端，直到他們也可以修復。 – 2009-06-26 14:48:13