使用关系数据库构建GitHub启发时间轴的设计模式?

vin*_*nux 11 php mysql symfony doctrine-orm

是否有用于构建GitHub灵感时间轴的设计模式?我正在尝试为我的应用程序编写一个有点复杂和多功能的时间轴系统.它基于这个概念:

[Subject] [Verb] [DirectComplement] [IndirectComplement] (metadata: [date])
Run Code Online (Sandbox Code Playgroud)

所以,在实践中:

John created a new post called Beautiful Post (12/01 00:01)
Run Code Online (Sandbox Code Playgroud)

约翰是主题,创造的是动词,美丽的帖子是直接的补充.

John commented "OMG" on Beautiful Post  (12/01 00:00)
Run Code Online (Sandbox Code Playgroud)

约翰是主题,评论是动词,"OMG"是直接的补充,而美丽的帖子是间接的补充.

我正在使用Symfony2和Doctrine运行MySQL.我创建了一个名为Timeline的实体,它将Subject,DirectComplement和IndirectComplement的模型以及它们的ID存储为字符串.然后,手动,我进行正确的查询,以获取每个对象.

使用Doctrine和MySQL有没有正确的方法呢?一种更优雅和多功能的方法,这不会让我疯狂,并迫使我做出一些荒谬的查询和foreachs?

vFr*_*sop 34

关于数据库架构

ActivityStrea.ms是社交活动流的标准提案,就像您想要的那样.这里有很多类似的帖子,主要是关于这些活动流的数据库设计(最后的链接).请不要低估ActivityStrea.ms JSON Schema的读数.我相信你会从中学到很多东西.

我建议你使用这个数据库设计:

user_id        |  INTEGER  |  user being notified
actor_id       |  INTEGER  |  user performing the action
activity_type  |  STRING   |  classname/type of the object being notified
activity_id    |  INTEGER  |  id of the object being notified
context_type   |  STRING   |  classname/type of the object's parent
context_id     |  INTEGER  |  id of the object's parent
read/view_at   |  DATETIME |  timestamp of when user saw it
Run Code Online (Sandbox Code Playgroud)

所以,例如,如果有人评论帖子,你会有类似的东西:

$notification = array(
    'user_id'       => $id_of_the_user_being_notified
    'actor_id'      => $comment->user_id
    'activity_type' => 'comment'
    'activity_id'   => $comment->id
    'context_type'  => 'post'
    'context_id'    => $comment->post_id
    'read_at'       => NULL
);
Run Code Online (Sandbox Code Playgroud)

似乎没有必要拥有所有这些领域,但他们肯定会付出代价.

通过该设计,您可以:

  1. 按用户,类型或上下文分组相关通知
  2. 按操作类型,上下文类型和特定参与者(通过联接)筛选通知
  3. 轻松清除已删除对象的通知(假设用户删除已注释的帖子.其注释的通知应消失)

注意:时间戳(created_at/updated_at)不是必需的.由于您将加载activity对象(在这种情况下为注释记录),因此您将拥有其时间戳.让它们重复的唯一原因是通过时间戳查询"通知"(您将无法在此处使用JOIN).无论如何,随意添加它们,如你所愿.

关于Doctrine和Symfony

我对Symfony说的不多,但我确信Doctrine支持多态查询.考虑到这一点,它应该与该设计很好地配合.

在Laravel上,我们使用模型实现的方法NotifiableInterface.这样,不同的模型可以有自己的逻辑,由谁得到通知,哪个是它的上下文.

应用程序本身会监听模型的create方法,并在适合时生成通知,因此模型和控制器本身不必处理通知,很好地解耦,更改存储应该尽可能简单.

NotifiableInterface的示例

这是一个非常简单的例子NotifiableInterface.您应该将它作为灵感,并根据您的需要进行调整.

interface NotifiableInterface {

    // Returns a string representation of the type
    // It may be a get_class($this), the model table
    // or anything you like really.          
    public function get_type();

    // Returns an identifier for the object (ie its ID)
    // get_key is for compatibility with Laravel models
    // but you may use get_id.
    public function get_key();

    // Returns the context object for this entity.
    // It's advisable that this object also implements
    // NotifiableInterface, so it also has get_type and get_key
    public function get_context();

    // Returns the user_ids to be notified.
    // A comment, for instance, should notify the post owner
    // as well as anyone else that commented that post.
    public function should_notify();

}
Run Code Online (Sandbox Code Playgroud)

相关问题

以下是一些有关该主题的丰富信息的帖子: