用于分布在多个表中的数据的 Kohana 模型
我正在将一个数据库驱动的网站与 kohana 放在一起,我需要能够跟踪修订。所以我有两个表中各个页面背后的数据。第一个是通用实体表,我用它来跟踪所有网站内容。它包含基本信息:资源uid、uri别名、创建用户、创建日期、发布用户、内容模型。修订表包含 rev_id、资源 uid(FK)、标题、页面内容、修订创建者、修订日期和发布审批者。
该站点将通过资源 uid 或 uri 别名查找页面并返回最新发布的修订版本。但是,用户可以从 uri 中将页面回滚到较早的修订版本,方法是在 uri 中包含日期上限或使用 -# 回滚 # 个修订版本。
因此,页面控制器将获取资源 uid(可能是日期)和修订回滚计数,从模型请求适当的记录,并将适当的记录传递到视图。
创建新页面将更新两个表,更新页面将更新一张表,删除表将影响 1 个表。
我应该创建两个模型:实体模型和修订模型吗?或者我应该只拥有一个抽象实际结构的逻辑模型?
I am putting together a DB driven website with kohana and I need to be able to track revisions. So I have the data behind the individual pages in two tables. The first is the generic entity table that I use for keeping track of all the sites content. It contains basic information: resource uid, uri alias, creating user, creation date, and publishing user, and content model. The revision table contains rev_id, resource uid as FK, title, page content, revision creator, revision date, and publish approver.
The site will lookup a page by resource uid or uri alias and return the most recent published revision. However from the uri the user can roll back the page to earlier revisions by including an upper date limit in the uri or a -# to roll back # revisions.
So the page controller will be taking in the resource uid, possibly a date, and a revision rollback count, requesting the appropriate record from the models, and passing the appropriate record to the view.
Creating new pages will update both tables, updating pages will update one table, and deleting tables will effect 1 table.
Should I be creating two models, the entity model and the revision model? Or should I just have the one logical model that abstracts the actual structure?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我遇到了类似的问题,并选择了两种模型的方式。
对不起,代码示例,我写它只是为了说明目的。
为了避免数据库结构更改出现问题,我只是从实体模型继承了修订模型,并重载了父字段(或者如果不需要它们,则取消设置它们)。
看起来像这样:
PS 请原谅我的英语
I had similar problem, and chose the way with two models.
Sorry for code sample, i wrote it only for illustration purposes.
To avoid problems with db structure changes, i just inherited revision model from entity model, and overloaded parent fields (or just unsetted them if i didnt need them).
Looked like this:
PS Excuse my english