数据库设计 - 文章，博客文章，照片，故事

3 回答

• 5

  这是为您的应用程序实现超类型/子类型表的一种方法 .

  首先是超类型表 . 它包含所有子类型共有的所有列 .

  CREATE TABLE publications (
    pub_id INTEGER NOT NULL PRIMARY KEY,
    pub_type CHAR(1) CHECK (pub_type IN ('A', 'B', 'P', 'S')),
    pub_url VARCHAR(64) NOT NULL UNIQUE,
    CONSTRAINT publications_superkey UNIQUE (pub_id, pub_type)
  );
  

  接下来是几个子类型表 .

  CREATE TABLE articles (
    pub_id INTEGER NOT NULL,
    pub_type CHAR(1) DEFAULT 'A' CHECK (pub_type = 'A'),
    placeholder CHAR(1) NOT NULL, -- placeholder for other attributes of articles
    PRIMARY KEY (pub_id, pub_type),
    FOREIGN KEY (pub_id, pub_type) REFERENCES publications (pub_id, pub_type)
  );
  
  CREATE TABLE stories (
    pub_id INTEGER NOT NULL,
    pub_type CHAR(1) DEFAULT 'S' CHECK (pub_type = 'S'),
    placeholder CHAR(1) NOT NULL, -- placeholder for other attributes of stories
    PRIMARY KEY (pub_id, pub_type),
    FOREIGN KEY (pub_id, pub_type) REFERENCES publications (pub_id, pub_type)
  );
  

  这些子类型表中的CHECK（）和FOREIGN KEY约束可防止行引用超类型中的错误类型的行 . 它有效地在子类型中划分pub_id值，保证任何给定的pub_id可以出现在一个且只有一个子类型表中 . 这就是为什么在列对{publications.pub_id，publications.pub_type}上需要PRIMARY KEY或NOT NULL UNIQUE约束的原因 .

  评论表很简单 . 鉴于所有子类型都具有相同的结构，您可以引用超类型 .

  CREATE TABLE comments (
    pub_id INTEGER NOT NULL REFERENCES publications (pub_id),
    comment_timestamp TIMESTAMP NOT NULL DEFAULT now(),
    commenter_email VARCHAR(10) NOT NULL, -- Only allow people who have 
                                          -- really short email addresses
    comment_text VARCHAR(30) NOT NULL,    -- Keep 'em short!
    PRIMARY KEY (pub_id, comment_timestamp, commenter_email)
  );
  

  添加一点数据 .

  INSERT INTO publications VALUES
  (1,'A', 'url 1 goes here'),
  (2,'A', 'url 2 goes here'),
  (3,'S', 'url 3 goes here');
  
  INSERT INTO articles VALUES
  (1,'A', 'A'),
  (2,'A', 'B');
  
  INSERT INTO stories VALUES
  (3,'S', 'A');
  
  INSERT INTO comments VALUES
  (1, now(), 'a@b.com','You''re stupid'),
  (1, now(), 'b@c.com', 'You''re stupid, too!');
  

  现在，您可以创建一个视图来显示所有文章并解决连接问题 . 你会为每个子类型做同样的事情 .

  CREATE VIEW articles_all AS
  SELECT P.*, A.placeholder
  FROM publications P
  INNER JOIN articles A ON (A.pub_id = P.pub_id)
  

  您可能更喜欢“published_articles”等名称而不是“articles_all” .

  要选择一篇文章及其所有注释，您只需 left join 这两个表 . （但请参阅下文，为什么你可能不会这样做 . ）

  SELECT A.*, C.*
  FROM articles_all A
  LEFT JOIN comments C ON (A.pub_id = C.pub_id)
  WHERE A.pub_id = 1;
  

  您实际上可能不会为Web界面执行此操作，因为dbms必须返回文章的'n'个副本，其中'n'等于注释的数量 . 但在某些应用程序中执行此操作确实有意义 . 在有意义的应用程序中，您将为每个子类型使用一个可更新视图，并且应用程序代码将在大多数时间使用可更新视图 .

  ---

  超类型/子类型较为常见的商业应用涉及"Parties"（超类），"Organizations"和"Individuals"（亚型，非正式的企业和人民 . 地址，就像上面的例子"comments"，都涉及到父，因为所有的亚型（组织和个人）有地址 .

  回复于 2024-05-04T11:49:14+08:00
• 35

  您可以在数据库设计中使用超类型/子类型来避免该问题 . 为图像，视频，笔记创建超类型，然后链接到超类型 . 将所有公共列保留在超类型表中 .

  以下是几个与模型相似的问题/答案的链接：

  • One

  • Two

  • Three

  • Four

  回复于 2024-05-04T11:49:14+08:00
• 1

  在我看来，你最好有4个单独的表格来评论 . 或者你可以加入表格 . 一个表用于所有评论...例如：博客表，评论表，blog_comment表 . 这将允许您拥有外键 .

  Blog
  --------
  Blog_id
  {other fields}
  
  Blog_Comment
  --------------
  Blog_id
  Comment_id
  
  
  Comment
  ------------
  Comment_id
  {other fields}
  

  回复于 2024-05-04T11:49:14+08:00