MySQL 性能 : Single Object With Multiple Types - JOIN scenario

Question

具有以下类型的表格设计:

http://www.martinfowler.com/eaaCatalog/classTableInheritance.html

为了示例，让我们使用以下架构:

CREATE TABLE `fruit` (
  `id` int(10) UNSIGNED NOT NULL,
  `type` tinyint(3) UNSIGNED NOT NULL,
  `purchase_date` DATETIME NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `apple` (
  `fruit_id` int(10) UNSIGNED NOT NULL,
  `is_macintosh` tinyint(1) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `orange` (
  `fruit_id` int(10) UNSIGNED NOT NULL,
  `peel_thickness_mm` decimal(4,2) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


ALTER TABLE `fruit`
  ADD PRIMARY KEY (`id`);

ALTER TABLE `apple`
  ADD KEY `fruit_id` (`fruit_id`);

ALTER TABLE `orange`
  ADD KEY `fruit_id` (`fruit_id`);


ALTER TABLE `fruit`
  MODIFY `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT;

ALTER TABLE `apple`
  ADD CONSTRAINT `apple_ibfk_1` FOREIGN KEY (`fruit_id`) REFERENCES `fruit` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `orange`
  ADD CONSTRAINT `orange_ibfk_1` FOREIGN KEY (`fruit_id`) REFERENCES `fruit` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

在这里，'apples' 和 'oranges' 是 'fruit' 的类型，具有独特的属性，这就是为什么它们被分割到自己的表中的原因。

问题是，从性能的角度来看，在执行 SELECT * FROM fruit 时查询，是否会更好:

a) 执行 LEFT OUTER JOIN在每个打字表上，即 apple和 orange (在实践中，我们可能会处理几十种水果)

b) 跳过连接并稍后对每个 fruit 执行单独的查询应用程序逻辑中的行，因此对于 fruit行类型 apple , SELECT * FROM apple WHERE fruit_id=... ？

编辑:至于具体的场景，我就不赘述了，这里实际的应用是一个通知系统，当某些事件发生时，它会产生通知。每种事件类型都有不同的通知类型，并且每种通知类型都存储该事件类型独有的属性。这是一个具有大量用户事件的网站，因此最终会有数百万行通知。

Answer 1

有一个包含“常见”属性列(例如，type='apple'、purchase_date=...)的表格，以及一个包含 JSON 的 TEXT 列包含适用于相关行的任何其他属性(例如，subtype='macintosh')。

或者将 subtype 作为通用属性可能更有意义，因为许多水果都有这样的属性(想想“肚脐”)。

您将如何处理“继承”？它在教科书中很棒，但它在数据库中很糟糕。 SQL 早于继承、面向对象等。