大型数据库架构与小型架构和 BLOB/CLOB XML

Question

我在 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 也存在性能问题。

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

提前致谢！

Answer 1

在使用过各种数据库技术的大型数据系统后，我建议不要使用 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 对象。