0

我在 StackOverflow 上搜索过,但没有找到这个讨论,所以我想在这里发布它以获取社区的意见。我也认为这个讨论可能也适用于其他团队,所以希望这是一个有用的帖子。如果这是一个重复的主题,请告诉我,我会删除它。

背景: 我从事一个相当大的合同软件项目,现在大约有 15 年的历史。该系统是一个客户端-服务器风格的应用程序,带有一个 SQL Server 数据库和一个在 Windows 上运行的用 MFC/C++ 编写的胖客户端。该应用程序的 API 完全是扁平的,非面向对象的,因为它完全封装在 COM 中。数据库大约有 780 个表,应用程序有超过 700 万行代码。在过去 8 年左右的时间里,大多数表格都已添加,并且随着新的增强请求正在酝酿中,我们不会很快看到这种放缓。最初的架构方法是将所有内容存储在表/列中,就像在类层次结构中一样。ORM 框架(Hibernate、Entity 等)如何工作以持久化数据。
在过去的几年里,我们的客户表达了重新架构系统并彻底重写应用程序的愿望,因为系统基本上已经超出了自身,并且受到 COM 的严重限制。我们有机会重新架构现代化系统,我们的一个问题是关于我们数据库的可扩展性。

主要问题: 由于我们现在有 780 个表,并且我们预计在不远的将来会打破 1000 个表,对我们来说继续使用这种架构方法或创建 10 到 20 个表并将几乎所有数据存储在一个BLOB 列作为 XML?700 多张桌子中可能有 600 张是为单亲班准备的,该班有大量的孩子和孩子的孩子等等。

我的想法: 我已经编写了两种方式的程序,并且我认为将数据作为 XML 存储在 blob 中可以显着提高性能,因为不会触发 100 或 1000 次查询来插入和检索数据。根据我的经验,解析 XML 的性能比处理 1000 个表的数据库要快得多。XML 方法的另一个优点是它通常不需要模式更改。另一方面,XML 也存在性能问题。

如果您知道,请发布有关此主题的想法、事实和任何研究。所有信息都会有所帮助和赞赏。

提前致谢!

4

1 回答 1

2

在使用过各种数据库技术的大型数据系统后,我建议不要使用 XML 来完成这项任务。

好消息是 SQL Server 当然支持 XML 数据类型,您实际上可以在 TSQL 中对 XML 运行相当复杂的查询。因此,您甚至不需要将 XML 抽取到您的应用程序中来创建一个存储过程作为示例。

我在关系数据存储中将序列化数据存储为 XML 时遇到的问题:

  1. 它很慢。在 SQL Server 中使用 XML 数据类型运行一些测试,您会发现在 TSQL 中检查它比返回“常规”数据要慢很多。

  2. 它太冗长了。XML 的大小比 JSON 之类的格式大很多。您将失去使用 JSON 查询 TSQL 中数据的能力,但是当对象变大时,节省空间是件好事。

  3. 在维护将 XML 存储在 SQL Server 中的遗留应用程序时,我无法告诉你有多少次我的头撞到了墙上。如果找不到最初序列化/反序列化 XML 的代码,那真是令人沮丧。现在看起来可能不是问题,但是当您在未来几年将其他新开发人员带入系统时,它就会成为问题。

  4. 这可能是个人喜好,但现在没有人使用 XML 来存储数据。JSON 是最新最好的。CouchDB、MongoDB、Elastic Search 等文档数据库都使用 JSON 作为他们的通用语。现在所有的工具也都使用 JSON。它仍然允许您轻松地序列化/反序列化对象,而且它更轻巧,在我看来阅读起来并不那么难看。=)

底线:

我至少会考虑一直使用文档数据库(MongoDB、CouchDB、Couchbase、Riak、Elastic Search)。不同的心态,但可能会让生活更轻松。

如果不是,那么我仍然会使用 blob,但强烈考虑使用 JSON。

如果没有这两个,我只会使用 SQL Server 中的 XML 数据类型来存储 XML 对象。

于 2013-06-03T22:37:56.700 回答