Question

我正在设计我的数据库，并希望了解处理此问题的最佳方法。我有一个页面上的标签，如下所示：

Tab1
--SubTab1
----Data1
--SubTab1
--SubTab1
Tab2
--SubTab1
--SubTab1
--SubTab1
Tab3
--SubTab1
--SubTab1
--SubTab1

我可以将此信息放在将存储在多行中的数据库中，如

TypeID---------------Name
1--------------------Tab
2--------------------Data


ObjectID----------Parent-------------TypeID
1-----------------0------------------1
2-----------------0------------------1
3-----------------0------------------1
4-----------------1------------------1

或者我可以把它放在数据库中，如下所示：

<root>
     <tab name="MyTab">
          <tab name="MySubTab">
               <data>1234567890</data>
          </tab>
     </tab>
</root>

如果我只从数据库中提取xml，那么我就不需要选择多行了，我只需要选择一行，然后将xml解析成一个类，然后将该数据传递给控制器。我只是想知道这是不是一个好主意？如果我的网站将来扩展，我会犯错吗？随着网站变得更大并想要更多功能，这会进行更多维护吗？

Answer 1

使用SQL很难查询XML。如果您认为永远不需要查询数据，则可以使用XML。我可能会将数据存储在多行中，以便将来灵活使用。

Answer 2

如果您的数据是xml的一大块，则无法使用数据库轻松搜索该数据。你需要在xml中搜索信息吗？将它分开将使这项任务更容易。

Answer 3

也许我误解了它，但似乎您决定是将数据保存为XML还是将其保存在表中，然后使用xml查询它以返回它。如果是这样的话：

更容易查询并且可以处理更多更改：如果您有很多更改并且它会以很高的速度增长，那么将数据保存到表并稍后查询会更好。您可以获得更多复杂查询的选择。

如果数据不会增长或变化那么快就会更快：如果数据不会经常发生变化并且没有增长的危险，那么您可以简单地使用XML将其保留在已经是正确的语法，它会降低性能。此方法意味着您在查询正确的数据方面灵活性较低。

Answer 4

如果您正在考虑是否在数据库上存储XML，现在是时候开始问自己是否需要将这些数据存储在数据库中。

如何将此数据存储在静态XML文件中？这是一个可行的选择吗？为什么不呢？

如果此数据不经常更改并且您不想将行程投入数据库，但您仍希望确保以后可以使用CMS编辑此数据，那么也可以创建一个批处理进程，使用数据库中的数据创建静态XML文件，然后您的应用程序将完全忽略此数据在数据库中的事实，只使用静态XML文件。批处理过程将按计划或按需运行。

对于不经常更改的数据，这是一种可扩展，可维护且高效的方法来解决此问题。

实现相同的一种方法是使用像ASP.net或PHP这样的服务器端技术从数据库表中为您生成XML，然后使用具有较长过期时间的输出缓存来确保生成过程确实如此不经常跑。

作为一般经验法则，在数据库字段上存储非原始数据或复杂数据通常不是一个好主意。

Answer 5

如果使用SQL Server，我只会使用hierarchyid。虽然这可以在TSQL中使用XML，但有几点需要注意。最重要的是让有序的XML回复，因为TSQL（2008）没有正确/完全支持position()。它需要一个有点混乱的连接到'索引器'列。（如果您回读整个 XML blob，这不适用，但这听起来像是手动解析客户端的头痛）。

hiearchyid允许轻松保存这些级别，使数据库保持更规范化的格式（RDBMS'设计可以在多列上有效工作，只需确保具有正确的索引），以及应该更容易处理 - 尤其是如果你还没有准备好潜入SPROC土地： - ）

hiearchyid代表父/子关系以及兄弟姐妹的排序（它可以真正整理模型）;它基于深度优先模型，适用于此类任务。

此外，使用XML可能不会保存任何内容（IIRC，[typed] XML实际上已分解为某种内部列设置）。如果需要，它（XML）更好地用作“输入/输出”消息格式（或“文档”）。

快乐的SQL'ing。

将数据保存为DB中的xml与保存多行数据

5 个答案: