Wordpressは投稿の複数のエントリを「リビジョン」として保存していると思いますが、それはスペースの非常に非効率的な使用だと思いますか？
もっと良い方法はありますか？gititはバージョン管理にGITを使用するWikiだと思いますが、どのように行われるのでしょうか。例えば。私のアプリケーションはPHPであり、データをコミットして取得するためにGITと通信する必要がありますか？
したがって、Webアプリにバージョン管理を実装する良い方法は何ですか（たとえば、ブログでは投稿コンテンツである可能性があります）
私は最近、そのようなシステムを実装しました。これは、以前と現在のリンクと共に、置き換えられたレコードの概念を使用しています。これを達成する最善の方法についてかなりの量の調査を行いました - 最終的に私が到達したモデルはWordpress (および他のシステム) に似ています - 変更を新しいレコードとして保存し、これを使用します.
利用可能なすべてのオプションを考慮すると、投稿などの作成済みコンテンツにとってスペースは最後の懸念事項です。メディア ファイルはより多くのスペースを占有し、いずれにせよデルタとして保存することはできません。
いずれにせよ、Git が機能する方法は、すべてのリビジョンのコンテンツ全体を保存するという点で実質的に同じですが、最終的にはデルタにパックされます (または要求された場合)。
1990 年にさかのぼると、SCCS または RCS を使用していましたが、空きディスク容量が 30MB しかないこともあり、ストレージ不足を回避するために効率的なバージョン管理が本当に必要でした。
スペースを節約するためにデルタを使用することは、最新のシステムで利用可能なストレージの平均量を考えると、関連するすべての悪化に本当に価値があるわけではありません。スペースの無駄だと主張することもできますが、圧縮されていないものを元の形式で保存する方が長期的にははるかに効率的であると主張します
また、マークアップは、特に wysiwyg エディターで編集する場合、デルタを含むプレーン テキストほどうまく機能しません。
例の記事の最新バージョンを含む 1 つのテーブルを保持します。
新しいバージョンが保存されたら、最新のバージョンを最初のテーブルに保持しながら、現在のバージョンをアーカイブ テーブルに移動し、バージョン番号を付けます。
アーカイブ テーブルは、プロパティ ROW_FORMAT=COMPRESSED (MySQL InnoDb の例) を使用して使用するスペースを減らすことができます。アクセスされることはめったにないため、パフォーマンスの問題にはなりません。はい、変更セットを保存するだけでなくオーバーヘッドが多少かかりますが、計算を行うと、記事は非常に圧縮可能なテキストであるため、ほとんどスペースがなくても膨大な量のリビジョンを保持できます。
たとえば、このページ全体のソース コードは 11Kb に圧縮されています。これにより、1Mb でほぼ 100 のバージョンが得られます。比較すると、通常の記事はかなり小さく、平均して 1 MB で 500 ～ 1000 の記事/バージョンを提供できます。あなたはおそらくそれを買う余裕があります。