在构建动态网站时，选择合适的内容存储策略至关重要。本文将探讨基于XML和关系型SQL数据库的内容存储方法，并分析它们的优缺点。
首先需要回答的问题是：数据应该存储在哪里？可以选择：
对于基础网站，存储在磁盘上的XML文件可能就足够了，因为它们不提供任何数据管理功能，如并发访问、索引、安全管理等。
虽然XML（或面向对象）数据库在某些特定情况下可能是最佳解决方案，但由于缺乏标准、拥有成本较高以及市场接受度有限，可能会考虑其他解决方案。同样，很可能不会选择专有存储，因为目标是构建网站，而不是自己的数据库系统。
传统的（关系型）SQL数据库似乎是一个合理的选择——它们价格合理且广泛使用。它们还针对高性能进行了优化，使其成为通用内容管理系统的正确解决方案。
既然选择了SQL数据库来存储数据和其他系统信息，如用户和权限，需要决定如何在数据库中存储内容。当前内容管理系统中可以看到两种基本方法：
将文档作为XML存储意味着将所有文档存储在单个数据库表中，该表有一个字段用于保存整个文档。
例如，DocumentXML字段包含如下XML文档：
<article>
<title>My first article</title>
<summary>This is a summary.</summary>
<articletext>This is full article text.</articletext>
<teaserimage>/articles/myfirst.gif</teaserimage>
</article>
如果习惯于标准的关系数据库模式，可能会想要为每种文档类型创建一个单独的数据库表。
可能还会想要将公共字段合并到一个Documents表中，同时保持文档类型特定字段在单独的表中。
这两种方法都有其优缺点。XML方法通常更容易实现，对变化更灵活。它适合于半结构化内容，例如具有几个纯文本部分的页面。
如果需要编辑半结构化、面向文本的内容，同时保持其与页面设计分离，将从这个选项中受益。可以随时通过修改页面模板设计来更改显示方式。
然而，当需要在页面上显示多个XML文档时，可能会遇到严重问题。考虑一下一个包含数十个商品的产品目录：当需要显示商品列表时，需要遍历所有数据库记录，检索XML文档，解析它，并渲染。
正如可以想象的，这并不简单，性能也不会是最优的。
此外，XML方法并不真正支持类型化数据（如整数、日期时间等），因为所有内容都被序列化为文本。如果决定使用XSLT按价格对产品进行排序，将按文本进行排序，这将导致排序不正确。还需要确保日期时间值或小数在正确的格式中被解析和显示。
在严格结构化数据的情况下，如产品规格，将从传统的关系数据库方法中受益。它允许轻松地从数据库中检索数据，并使用标准的ASP.NET控件（如DataGrid）在网站上显示它们，同时完全控制格式。
还可以轻松地在数据库服务器上对它们进行排序或过滤，同时利用提供最佳性能的索引。然而，这种方法带来了在下面段落中讨论的几个挑战。
传统的SQL方法（按设计）对于内容管理来说不够灵活。数据库结构对变化不够灵活。
假设人力资源经理想要为这个职位发布年度薪水。通常需要做的是：
解决这个问题的方法是为代码添加一个“元”层。与其手工编写所有代码或生成代码，可能想要创建一个系统，其中描述数据结构或编辑表单，让内容管理引擎处理它。
在Kentico CMS for .NET中，当想要为文档类型添加一个新字段时，只需使用基于Web的用户界面，并向文档类型“Job”添加一个新属性。还指定这个属性是小数类型，并且应该在编辑表单中显示为文本框：
系统自动更新相关的数据库表：
它还更新了INSERT、UPDATE、SELECT和DELETE的标准SQL查询：
现在当编辑工作文档时，将看到一个动态渲染的编辑表单，如下所示：
唯一需要手工编码的是向Repeater或DataList的ItemTemplate部分添加一个适当的字段：
网站上的文档看起来像这样：
可能想知道这在内部是如何工作的：所有文档类型（新闻、工作、产品规格）都使用配置文件描述，这些文件定义了：
下图显示了这些元素如何协同工作：
CMS引擎接收到页面请求。它读取给定文档类型的设置（SQL查询等）。它运行一个SQL查询来从数据库中选择数据。然后，它将检索到的DataSet绑定到Repeater控件（或其他控件），该控件使用预定义的转换显示内容。页面显示给访问者。
正如看到的，XML和SQL导向的方法在内容管理世界中都有一席之地。它们都有各自的优缺点，需要根据具体情况选择它们。
现在，可以下载Kentico CMS for .NET的免费试用，并亲自尝试一下。Kentico CMS教程将指导通过创建具有XML导向和SQL导向设计的网页的过程。
任何语言——Kentico CMS使用UNICODE编码所有内容。