2010-03-23 81 views
23

我正在開發一個表單生成器,並且想知道如果將JSON存儲到SQL數據庫中是否是不好的mojo?將json存儲在msSQL數據庫中?

我要保持我的數據庫&表簡單,所以我將不得不

`pKey, formTitle, formJSON` 

桌子上,然後存儲

{["firstName":{"required":"true","type":"text"},"lastName":{"required":"true","type":"text"}} 

在formJSON。

任何輸入表示讚賞。

回答

29

我在我的CMS(主機大約有110個站點)中廣泛使用JSON,並且我發現訪問數據的速度非常快。我很驚訝沒有更多的速度退化。 CMS中的每個對象(頁面,佈局,列表,主題等)都有一個名爲JSONConfiguration的NVARCHAR(MAX)列。如果需要,我的ORM工具知道要查找該列並將其重新組合爲對象。或者,根據具體情況,我只會將它傳遞給客戶端以供jQuery或Ext JS處理。

至於我的代碼的可讀性/可維護性,您可能會說它有所改進,因爲我現在有類表示存儲在數據庫中的很多JSON對象。

我使用JSON.net進行所有序列化/反序列化。 http://james.newtonking.com/default.aspx

我也使用單個查詢來返回meta-JSON與實際數據。和Ext JS一樣,我有查詢返回Ext JS對象的結構以及對象需要的數據。這削減了一個回發/ SQL往返。

我還驚訝於代碼解析JSON對象列表的速度有多快,並將它們映射到DataTable對象中,然後將它們交給一個GridView。

我看到使用JSON的唯一缺點是索引。如果您有需要搜索的JSON屬性,則必須將其作爲單獨的列存儲。

有JSON DB的可能會更好地滿足您的需求:CouchDB,MongoDB和Cassandra。

3

它會比代碼中定義的表單慢,但一個額外的查詢不應該造成很大的傷害。 (只是不要讓一個額外的查詢成爲10個額外的查詢!)

編輯:如果您選擇的行由formTitle而不是pKey(我會,因爲那麼你的代碼將更具可讀性),索引formTitle

1

我不會推薦它。

如果你想在未來基於這些值做任何報告或查詢,它會讓你的生活比擁有一些額外的表/列更難。

爲什麼你要避免製作新表格?我說如果你的應用程序要求他們繼續並將它們添加進來...另外,如果有人必須通過你的代碼/分貝後,它可能會更難以弄清楚你所做的(取決於什麼樣的你有文件)。

+0

我們花了很多時間在自定義表單,通常包含相同的信息,大多數的這些信息被存儲到只有3-4個不同的表。因此,如果我可以通過編程方式創建表單,並將它們提交到適當的表格中,那麼將來可以節省大量的開發時間。 – JKirchartz 2010-03-23 15:15:33

+0

我認爲在這種情況下它可能會很好。就像邁克爾說的那樣,它只是一個額外的查詢。我以爲你試圖存儲值與表單的結構一起。 – 2010-03-23 22:57:22

7

從sql server製作對象數據庫的絕妙方法。我爲所有配置對象和其他不需要任何特定查詢的其他任何對象執行此操作。擴展你的對象 - 很簡單,只需在你的類中創建一個新的屬性,並使用默認值初始化。不再需要財產?只需在課堂上刪除它。輕鬆推出,輕鬆升級。不適合所有對象,但是如果您提取需要索引的任何道具,請繼續使用它。非常現代的使用sql server的方式。

+18

我遇到過許多場合,我正在尋找解決方案並在這裏找到我的方式。在尋找解決方案時,我有時會在其他地方找到更好的答案,或許使用更新的技術,而不是當時的答案。這不僅僅是爲了回答你的問題,而是爲了所有未來遇到同樣情況的人。和KOPEHb一樣,我會很有禮貌地更新甚至提供比解答更好的解決方案。 – Levitikon 2011-09-23 21:00:06

2

您應該可以使用SisoDb。 http://sisodb.com

+0

使用SisoDB後有沒有人有任何意見?它看起來很有希望,但是這種類型的庫在實際使用時可能會碰到或錯過...... – 2012-03-08 21:36:33

+1

嗨,我有點偏見,因爲我構建了SisoDB,但我們正在將它用於今天正在開發的商業產品中。它用於在CQRS環境中維護readmodels。 – Daniel 2012-03-10 11:39:50

3

我們已經使用了XML的修改版本來完全符合您描述爲期七八年的目的,並且它的效果很好。我們客戶的表格需求非常多樣,以至於我們永遠無法跟上桌/列的方式。我們在XML方面做得太差了,很容易改變,但我認爲JSON也可以工作,也許更好。

報告沒有問題,有幾個良好的解析功能,我會藐視任何人在我們的報告/分析與表/列解決方案之間找到顯着的性能差異來滿足這種需求。

1

我認爲在SQL中將對象數據存儲在字符串中並不是一個理想的想法。你必須在SQL之外進行轉換才能解析它。這會帶來性能問題,並且會失去使用SQL本機數據解析功能的優勢。更好的方法是將JSON存儲爲SQL中的XML數據類型。通過這種方式,您可以一箭雙鵰:您不必創建表的shit加載,仍然可以獲得SQL的所有本機查詢優勢。

XML in SQL Server 2005? Better than JSON in Varchar?