ウィキやマークダウンなど、ユーザーが入力したマークアップを処理する際に役に立ったアドバイス。CPU とデータベース スペースの両方のコストがかかるため、どちらに行けばよいかわかりません。
マークアップをデータベースに保存し、ページビューごとにサーバーで html にレンダリングします。(データベース容量は少なくなりますが、CPU 使用率は高くなります)
マークアップをデータベースに保存し、javascript を使用してクライアントで HTML にレンダリングします。(実装は難しいかもしれません)
レンダリングされた html だけをデータベースに保存し、編集が必要な場合はマークアップに戻します。(繰り返しますが、実装が難しい可能性があります)。
HTML とマークアップの両方をデータベースに保存します。(データベース スペースを 2 倍にします)。
他の何か。
(私は MFC と Linqtosql を使用しています)。
それを Wiki マークアップとしてデータベースに保存し、変換された HTML 出力をメモリ内の Web サーバー上のキャッシュに保持します。使用している Web テクノロジに関係なく、すべてがこれをサポートする必要があります。これは、URL や ID などをキーとする基本的なタプル (ハッシュテーブル) です。
それを RST マークアップとしてデータベースに保存し、必要に応じて HTML に変換します。おそらくフロントエンド (JSP、PHP、Django など、テンプレート言語をレンダリングするもの) を使用しているので、RST の追加処理によって大きなオーバーヘッドが発生することはありません。
複雑なキャッシュ メカニズムの実装を決定する前に、マークアップを HTML にレンダリングする実際のオーバーヘッドを実際に測定します。
「(データベース容量は少ないが、CPU 使用率は多い)」は測定された事実ではなく、真実ではないことが判明する可能性がある仮定です。
マークアップを保存し、その場で html サーバー側をレンダリングします。サーバー側のキャッシュを使用して、実行する実際の計算の量を減らすことができ、合理的なセマンティクスを持ち、必要に応じて text/html/pdf にレンダリングできる表現を維持できます。
最も簡単な方法は、マークアップを保存し、レンダリングのタイムスタンプを使用して、オンデマンドで HTML をキャッシュ (ディスクまたは memcached onject で可能) にレンダリングすることです。そうすれば、マークアップが変更されたために再度レンダリングする必要があるのか、それとも単にキャッシュされた HTML を提供するだけなのかを確認できます。これは、ほとんどの Ruby on Rails アプリ/CMS が動作する方法です。