性能數據存儲對象

我繼承了一些編程任務從我coleagues（< -spelling），與我給出一個用戶表結構這樣：性能數據存儲對象

userID BigInt (1,1) 
Username Nvarchar(100) 
UserPass Nvarchar(100) 
Profile Nvarchar(max)

他們所有編程邏輯的用戶名/密碼，客戶又回到他們身上，並聲明「我們現在想要用戶配置文件」。由於客戶端已經擁有對數據庫的控制權，我們不允許對現有存儲對象進行修改，但是，他們確實爲我們提供了新的配置文件字段。

我想知道的是：什麼會更好的表現...？任何地方都有基準嗎？

A)Storing profile data as XML 
B)Storing profile data as JSON 
C)Storing profile data as a comma-delimited list 
D)Other that I have not thought of...maybe store a XML file in the filesystem tied to the userID?

對於上述任何情況，我將輸入並打入對象。我個人會說JSON，並且我可以利用JSON.Net庫

p.s.這將在.Net 4和Win2k8 R2服務器上的SQL 2008 R2（這是個人的，他們是非常強大的）

來源

2012-11-30 Kevin

我認爲XML和Json都可以接受在這種情況下看到，因爲你被迫存儲這種方式的配置文件。

我在過去使用過XML，主要用於查找相關配置文件屬性時的結構和可讀性。

如果你擔心這個大小（id想象它會很小，雖然），存儲xml在壓縮狀態。

來源

2012-11-30 13:39:10 niallNoigeallach

是的，沒有真正擔心的大小，因爲我相信它會根據人們填寫他們的個人資料而大不相同。但我必須至少在基本的個人資料信息......手機，電子郵件，地址，或許一些社交網絡的東西，IM的東西，頭像等...... – Kevin

抱歉，我想我關心的大小，因爲我在詢問表演...... DOH！ – Kevin

但相對於類似用戶配置文件的時間量來說，大小相當無關，除非： 1. xml/json的大小很大。 2.有10個成千上萬（如果不是幾千個）用戶如果它是一個web應用程序，id想象你正在登錄數據庫並緩存用戶配置文件？ – niallNoigeallach

性能數據存儲對象

回答

相關問題