Asp.net CMS solution: the best data storage engine in SQL

I have worked on several CMS systems using the .NET framework (the CMS is in ASP.NET and the site that displays the content is both ASP.NET and PHP).

I have traditionally saved the generated content in classes that are serialized to XML, which is stored in MSSQL 2005/2008 in a varchar (max) field. This simplified the structure for different content users to work with and can be bound to classes (to reopen the CMS record and edit it, or for a consumer site).

However, I was wondering what type of storage engine is popular with other CMS stores and if anyone likes or has a major problem with the approach I'm most familiar with.

Okay, bad, ugly? What would you do?

+1


source to share


3 answers


I personally treat the data like any other data that will be stored in the system, for example, I have a module created for DNN that stores a collection of text data. I have the following set of columns in my table for it.

  • EntryID
  • UpdatedBy
  • UpdatedDate
  • CreatedBy
  • CreatedDate
  • SortOrder
  • Content (NTEXT)
  • Hidden (bit)


I find this makes the data easy to find, and easy to manipulate regardless of the caller.

+1


source


In our CMS, we use a structure similar to that described by Mitchel Sellers, but we separate its contents in our table. This is useful when optimizing your database and makes it easy to share functionality for content versioning. We then have one table per "type of object" like documents, products, etc., where we describe the object.



0


source


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

The main advantage of this is that the data in the database reflects what is actually entered by the user. Storing the XML in a SQL database just adds a redirection layer 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.

One problem you may run into is the difficulty of reusing existing SQL search engines with XML data.

0


source







All Articles