私は、.NET プラットフォームを使用する多数の CMS システムに取り組んできました (CMS 管理システムは ASP.NET にあり、コンテンツをレンダリングするサイトは ASP.NET と PHP の両方です)。
私は従来、生成されたコンテンツを XML にシリアル化するクラスに格納してきました。これは、MSSQL 2005/2008 の varchar(max) フィールドに格納されています。これにより、コンテンツのさまざまな消費者が作業するのに構造的に便利になり、クラスにバインドできます (CMS レコードを再度開いて編集するため、または消費する Web サイトのために)。
しかし、他の CMS ショップで人気のあるストレージ メカニズムのタイプと、私が最もよく知っているアプローチが好きな人や深刻な問題を抱えている人がいるのだろうかと考えていました。
良い、悪い、醜い？あなたならどうしますか？
私は個人的にデータをシステムに保存される他のデータとして扱います。たとえば、テキスト データのコレクションを保存する DNN 用に構築されたモジュールがあり、そのためのテーブルに次の列のコレクションがあります。
これにより、データが見つけやすくなり、呼び出し元に関係なく簡単に操作できることがわかりました。
私たちのCMSでは、ミッチェルセラーが説明しているものと同様の構造を使用していますが、コンテンツを独自のテーブルに分けています。これはデータベースを最適化するときに役立ち、コンテンツのバージョン管理のための機能を簡単に共有できます。次に、ドキュメントや製品などの「エンティティタイプ」ごとに、エンティティを説明する1つのテーブルがあります。
私たちは主力製品として ASP.NET CMS を持っているので、この問題はよく知っています。「生成されたコンテンツ」の意味によって異なります。ユーザーが入力するという意味であれば、ページ要素ごとに柔軟なフィールド セットを使用できるようにするテーブル構造を使用して、HTML を ntext およびその他のページ要素として保存します (1 つまたは 2 つのフィールドを使用して構成されたものもあれば、数十個のフィールドを使用して構成されたものもあります)。
これの主な利点は、データベース内のデータがユーザーによって実際に入力されたものを表すことです。XML を SQL データベースに格納することは、必要のないリダイレクトのレイヤーを追加するだけです。SQL を OO ストアのように機能させようとしている可能性がありますが、これは ORM が解決に役立つ典型的な問題です。
遭遇する可能性のある問題の 1 つは、既存の SQL 検索メカニズムを XML データで再利用するのが難しいことです。