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

Fau*_*ust 23 database-design

我正在为一个网站设计一个数据库,该网站至少会有4种不同的对象类型(文章,博客文章,照片,故事),每个对象都有不同的数据要求来保证自己的表格.我们希望用户能够发布任何这些类型的评论.评论的数据要求很简单,与评论所关注的事物类型无关(即只是评论主体和作者的电子邮件).

我想避免为注释创建和管理4个以上的单独表的冗余,所以我希望能够在一个表中保存所有注释,可能通过2列指定关系:一个用于指定父实体和一个对于父行Id.

但是我不明白我是如何实现外键的,因为外键在2和2个表之间建立关系(对吗?).

因此,考虑到所有这些,最好的方法是什么?

Mik*_*ll' 37

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

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

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)
);
Run Code Online (Sandbox Code Playgroud)

接下来是几个子类型表.

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)
);
Run Code Online (Sandbox Code Playgroud)

这些子类型表中的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)
);
Run Code Online (Sandbox Code Playgroud)

添加一点数据.

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!');
Run Code Online (Sandbox Code Playgroud)

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

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

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

要选择一文及其所有评论,你可以离开加入的两个表.(但请看下面你为什么不这样做.)

SELECT A.*, C.*
FROM articles_all A
LEFT JOIN comments C ON (A.pub_id = C.pub_id)
WHERE A.pub_id = 1;
Run Code Online (Sandbox Code Playgroud)

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


超类型/子类型更常见的业务应用涉及"缔约方"(超类型),"组织"和"个人"(子类型,非正式公司人员.地址,如上例中的"注释")与超类型,因为所有子类型(组织和个人)都有地址.

  • @Snake:这不是一个坏主意,但它不是连接所必需的,而且你不需要动态SQL.(如果可能,动态SQL具有更好避免的风险.)'n'子类型的超类型/子类型设计映射到'n'+ 1个基表和'n'个视图.每个'n'视图将超类型表连接到一个子类型表; 然后客户端使用视图,而不是基表.(如果需要,写入触发器,让您通过视图执行INSERT,UPDATE,DELETE.)一旦有了一个命名良好,可更新的视图,您就不需要自己读取该列.它只是帮助SQL维护数据完整性. (5认同)
  • @Snake:我理解你在说什么,但如果你使用的是SQL dbms,你真的需要那个列和复合键.在超类型和每个子类型中实现并用作复合键和外键引用的一部分的CHAR(1)列保证了超类型表中的每一行都可以连接到一个且只有一个行连接到一个且只有一个子类型表.没有它,你可以在每个子类型表中插入相同的pub_id,这使得超类型/子类型设计无用. (5认同)
  • @Snake:CHAR(1)足够长,足够可读,占用的空间比整数少.使用CHAR(1)可能会获得稍微好一点的性能,或者使用整数可能会获得稍微好一点的性能.但我通常更喜欢文本到数字,因为我发现阅读文本更容易.(A)rticle,(B)log post,(S)tory比(1)文章,(2)博客文章,(3)故事更容易记住.我不介意花时间; 你不应该介意支持我的每一个回复.我的原始答案也是如此.;) (5认同)
  • @Catcall:谢谢。清楚地了解视图的使用。我有点知道这一点,但没有很好地思考这个问题。另一个问题:我的计划是依赖 Publications 表来生成 Pub_Id——然后将其复制到子类型表中,因此该值在每个表中都是唯一的,因此我不需要复合出版物表上的主键。那有意义吗? (3认同)
  • @CatCall:回到最后一个问题:鉴于pubtype在主键中的作用,是否存在性能原因或其他原因使其保持为1个字符?如果是这样,int会更好吗?(顺便说一下:感谢你的时间和耐心.请原谅我对这些事情的"密度".我的经验主要是前端,但这次我是一个单人项目;幸运的是,我已经成功游说了很多时候所以我可以认真思考.) (2认同)
  • @Snake:在没有任何其他约束的情况下,超类型中的复合键将允许相同的 ID 号与两个或多个子类型表相关联。但是超类型/子类型设计的特点是超类型中的每一行必须与*仅*一个子类型表中的*仅*一行相关联。因此,在没有其他约束的情况下,像这样的复合键会破坏设计。(但请注意,虽然主键是单列,但备用键是复合键。SQL 要求 FK 约束才能工作。) (2认同)
  • 我知道这是一个旧线程,但是 FWIW - 我在 15 年的关系数据库编程中从未遇到过在数据库中使用子类型/超类型以任何有意义的方式有益的情况。事实上,这往往是有害的。以我的经验,这会导致极其混乱的应用程序代码,维护和扩展成本高昂。 (2认同)

Dam*_*vic 5

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

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

  • 你的意思是创建一个图像,视频笔记而不是超类型的子类型? (2认同)