asp.net CMS 解决方案:在 SQL 中存储数据的最佳机制

发布于 2024-07-09 00:41:03 字数 312 浏览 11 评论 0原文

我曾使用.NET 平台开发过许多CMS 系统(CMS 管理系统采用ASP.NET,呈现内容的站点同时采用ASP.NET 和PHP)。

传统上,我将生成的内容存储在序列化为 XML 的类中,该类存储在 MSSQL 2005/2008 中的 varchar(max) 字段中。 这使得内容的不同使用者在结构上变得方便,并且可以绑定到类(用于重新打开 CMS 记录并对其进行编辑,或用于消费网站)。

然而,我一直想知道其他 CMS 商店流行什么类型的存储机制,以及是否有人喜欢我最熟悉的方法或对我最熟悉的方法有严重问题。

好、坏、丑? 你会怎么办?

I've worked on a number of CMS systems using the .NET platform (the CMS management system is in ASP.NET, and the site which renders the content is both ASP.NET and PHP).

I've traditionally stored the generated content in classes that serialize to XML, which is stored in MSSQL 2005/2008 in a varchar(max) field. This has made it convenient structuarally for different consumers of the content to work with, and it can be bound to classes (for re-opening the CMS record and editing it, or for the consuming website).

However, I've been wondering what type of storage mechanism is popular with other CMS shops, and if anyone likes or has serious issue with the approach I'm most familiar with.

Good, bad, ugly? What would you do?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

疯了 2024-07-16 00:41:03

我个人将数据视为将存储在系统中的任何其他数据,例如,我有一个为 DNN 构建的模块,用于存储文本数据的集合,我在表中拥有以下列的集合。

  • EntryId
  • UpdatedBy
  • UpdatedDate
  • CreatedBy
  • CreatedDate
  • SortOrder
  • 内容 (NTEXT)
  • 隐藏(位)

我发现这使数据易于查找,并且无论调用者是谁,都可以轻松操作。

I personally treat the data as any other data that would be stored in the system, for example I have a module built for DNN that stores collection of text data, I have the following collection of columns in a table for it.

  • EntryId
  • UpdatedBy
  • UpdatedDate
  • CreatedBy
  • CreatedDate
  • SortOrder
  • Content (NTEXT)
  • Hidden (Bit)

I find that this keeps the data easy to find, and it is easy to manipulate regardless of the caller.

清醇 2024-07-16 00:41:03

在我们的 CMS 中,我们使用与 Mitchel Sellers 描述的结构类似的结构,但我们将内容分隔在自己的表中。 这在优化数据库时非常有用,并允许我们轻松共享内容版本控制的功能。 然后,我们为每个“实体类型”(例如文档、产品等)提供一个表,在其中描述实体。

In our CMS we use a similar structure to the one Mitchel Sellers describe, but we separate the content in its own table. This is useful when optimizing the database and allows us to easily share the functions for versioning of content. We then have one table per "entity type" like documents, products and so on, where we describe the entity.

差↓一点笑了 2024-07-16 00:41:03

我们的主要产品是 ASP.NET CMS,所以我很熟悉这个问题。 这取决于您所说的“生成的内容”是什么意思。 如果您指的是用户输入的,那么我们使用表结构将 HTML 存储为 ntext 和其他页面元素,该结构允许我们为每个页面元素拥有一组灵活的字段(有些使用一个或两个字段进行配置,其他则有数十个字段)。

这样做的主要好处是数据库中的数据代表用户实际输入的内容。 将 XML 存储在 SQL 数据库中只是添加了一层我们不需要的重定向。 您可能试图让 SQL 像 OO 存储一样工作,这是 ORM 帮助解决的典型问题。

您可能遇到的一个问题是很难对 XML 数据重新使用现有的 SQL 搜索机制。

We have an ASP.NET CMS as our main product so I'm familiar with the problem. It depends what you mean by "generated content". If you mean user-entered, then we store HTML as ntext and other page elements using a table structure that allows us to have a flexible set of fields per page element (some are configured using one or two fields, others have dozens).

The main benefit of this is that the data in the database is representative of what is actually entered by the user. Storing XML in a SQL database is just adding a layer of re-direction that we don't need. You might be trying to get SQL to act like an OO store, which is a typical problem that ORMs help solve.

One problem you may come across is difficulty in re-using existing SQL search mechanisms with XML data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文