2010-03-23 130 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?