在SQL中，我可以返回具有不同列數的表格

Question

我有一個更復雜的場景，但我認爲它應該是可能的。

我有一個大的SPROC，其結果是一組人的一組特徵。

所以表會是這個樣子：

 
Property |	 Client1 	 Client 2	 Client3 
----------------------------------------------------------- 
Sex  |	 M  	 F  	 M 
Age  |	 67  	 56  	 67 
Income |	 Low  	 Mid 	 Low 

它使用了遊標，遍歷不同的數據集構建的。

我現在面臨的問題是，有不同數量的客戶端和屬性的，所以在不同的輸入設置一個同樣有效的結果可能是：

 
Property |	 Client1 	 Client 2 
------------------------------------------- 
Sex  |	 M  	 F 
Age  |	 67  	 56 
Weight |	 122  	 122 

不同數量的屬性是很容易，這些都是隻是額外的行。

我的問題是，我需要聲明一個不同數量的列的臨時表。

可能有2個客戶或100個。每個客戶保證每個物業最終上市。

什麼SQL結構可以統計這個，我該如何聲明它並在其中插入東西？

我不能只是將列和行翻轉，因爲每個列都有可變數目。

Answer 1

首先，你要考慮你的規範化設計，像這樣：

Create Table ClientAttributes 
(
    ClientId .... 
    , Sex Char(1)... 
    , Age int... 
    , Income... 
) 

其次，在一般的SQL語言不減速用於動態列生成。爲了達到這個目的，你必須在運行時（也稱爲動態SQL）將SQL語句作爲一個字符串來構建。最好在中間層或報告引擎而不是T-SQL中執行此操作。第三，一個無限靈活的設計，你不知道屬性或實例的數量或類型，根本不是設計。每個表格代表具有已知屬性的實體的集合。他們不是任意數據。在設計時需要知道屬性（列），否則你就冒着一種只有混沌繮繩才能完成的克蘇魯設計的風險。

休斯的建議是使用實體屬性值設計（也稱爲EAV）。需要一個巨大的紀律來正確地做一個EAV。它只在被視爲一團數據時纔有效。也就是說，沒有開發人員能夠過濾任何特定的屬性（即硬編碼查詢特定屬性名稱的查詢），曾經計算過這些值，並且永遠無法確保特定值之間的一致性。如果你能保持這種紀律，那麼任意一組數據作爲一個有限的部分可以工作。然而，一旦你決定硬編碼查詢尋找一個特定的屬性，你已經走下了黑暗的道路，並永遠支配你的命運。隨着數據庫的增長，性能將顯着下降。您將沒有數據完整性（例如，您有兩個名爲「Age」和「Client Age」的屬性，其中一些值爲整數，其他爲文本）。 EAV可能是一個噩夢來維護。維護，報告，查詢等都有一個標準化的設計。

Answer 2

這看起來像你在服務器*上使用Pivoting。

雖然你可以做到這一點，但處理起來會非常尷尬 - 而且我不知道任何可以爲你工作的ORM（如果沿着這條路走下去的話）。

相反的樞轉，如何安排它更像（* 2）：

Client | Property | Value 
------------------------------ 
Client 1| Sex  | M 
Client 1| Age  | 67 

這樣你仍然可以做到這一點每個客戶端的擺動在應用程序中進行顯示。

（* FWIW：你知道2005+具有PIVOT Commands，對SQL Server要您使用遊標保存？）

（* 2這只是一個可能方法這是哈克，和托馬斯的建議。 。您的規範化模式是一個更好的和（可能）更有效的選擇）