内容版本控制

发布于 2024-11-02 13:23:43 字数 236 浏览 5 评论 0原文

我刚刚开始一个项目,我想要一个带有版本控制的小型内容管理器。但是我不知道对数据库建模的最佳方法是什么。

我有包含以下字段的内容表: id 主键序列号, content_id int(标识不同内容的字段), 标题varchar, 内容长文本, 版本 int 默认 '1', create_date 日期,

我看到一些 CMS 将另一个表中的修订版与实际修订版分开,最好的方法是什么?有什么优化的办法吗?

谢谢!

I just starting a project, I would like to have a small content manager with version control. However I don't know what is the best way to model the database.

I have content table which contains the following fields:
id primary key serial,
content_id int (field to identify diferent contents),
title varchar,
content longtext,
version int default '1',
create_date date,

I have seen some CMS separes the revisions in another table than the actual revision, What's the best way? Is there any optimized way?

Thanks!

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

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

发布评论

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

评论(2

月牙弯弯 2024-11-09 13:23:43

这已经存在,没有数据库:

  • gitit (用 Haskell 编写,使用 git 或 darcs 作为后端)
  • ikiwiki (用 Perl 编写,可以使用各种版本控制系统作为后端)

它们都是开源的,并且都有插件架构,因此可以根据您的具体需求进行定制。 (但是,我只使用过 gitit。)不过

,我要指出的是,git 在对大型二进制文件进行版本控制方面并不完美,而 darcs 在这方面表现很糟糕。需要注意的事情。

This already exists, without a database:

  • gitit (written in Haskell, uses git or darcs as a backend)
  • ikiwiki (written in Perl, can use various version control systems as a backend)

They're both open source, and both have a plugin architecture, so can be customised for your specific needs. (However, I've only used gitit.)

I would however note that git is not perfect at versioning large binary files, and darcs is terrible at it. Something to watch out for.

于我来说 2024-11-09 13:23:43

我设计了这样的东西,这就是它的要点;

  1. 我为每个想要进行行级版本控制的表创建镜像表。假设您有 CUSTOMER 表。您的镜像版本控制表将是 VER_CUSTOMER
  2. 我想要进行行级版本控制的每个表都有一个名为 RECORD_ID (GUID) 的列。
  3. 当将记录插入该表时,我会生成新的 GUID 并填充该字段。新记录也插入到 VER_CUSTOMER 表中,其中 RECORD_ID 添加到表的自然 PK 中。
  4. 当记录更新时,我再次生成新的 GUID。使用这个新的 GUID 填充 RECORD_ID。更新的记录也会进入 VER_CUSTOMER 表。
  5. 当记录被删除时,我将 CUSTOMER 表上的记录标记为 DELETED (不是物理删除记录)。我的每个表上都有 IS_DELETED 列。当尝试删除记录时,我将该列设置为 TRUE。同样,已删除记录的副本也会进入 VER_CUSTOMER 表。

因此,该表上的每笔交易都会在 VER_CUSTOMER 表中具有相应的记录,其中 RECORD_ID 和表的自然 PK 为 PK。例如,如果 CUSTOMER 表的 PK 是 CUST_ID。 VER_CUSTOMER 的 PK 将是 CUST_ID 和 RECORD_ID 的复合。

希望这有帮助...

I designed something like this and here's the gist of it;

  1. I create mirror table for every table that I want to have row level version control. Let's say you have CUSTOMER table. Your mirror version control table will be VER_CUSTOMER
  2. Every table that I want to have row level version control has a column called RECORD_ID (GUID)
  3. When a record inserted to that table, I generate new GUID and populate that field. New record also inserted into VER_CUSTOMER table with RECORD_ID as added to table's natural PK.
  4. When record is updated, I generate new GUID again. Populate RECORD_ID with this new GUID. Updated record also goes to VER_CUSTOMER table.
  5. When record is deleted, I mark record on CUSTOMER table as DELETED (not physically delete the record). I have IS_DELETED column on every table. I set that column to TRUE when record is attempted to be deleted. Again copy of the deleted record also goes into VER_CUSTOMER table.

So every transaction that you have on that table, you have a corresponding record in VER_CUSTOMER table with RECORD_ID and table's natural PK as PK. For example if CUSTOMER table's PK is CUST_ID. PK of VER_CUSTOMER will be composite CUST_ID and RECORD_ID.

Hope this helps...

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