我正在权衡Concrete和Class Table继承(参见下面的示例)。 Class Table肯定有很多好处,特别是对于我的场景,超级表列在整个数据集中保证一致。但是我接下来不需要一次查询每个子类,而是所有查询一次只能在一个子类上(其中至少有9个子类)。
因此,当我的行数看起来非常大时,查询一个具有较少行的Concrete表会更加快速,即: (如下例所示)
SELECT property_address
FROM policies_property
ORDER BY date_issued DESC;
或者外键关系是否足够快,以至于查找超大型超级表的查询速度差异在类表继承中可以忽略不计: (如下例所示)
SELECT property_address
FROM policies_property INNER JOIN policies_super ON policies_property.id = policies_super.id
ORDER BY policies_super.date_issued DESC;
具体继承的示例:每个类型的完全独立的表,每个表中都有重复的列>
--// Table: policies_motor
+------+---------------------+----------------+
| id | date_issued | vehicle_reg_no |
+------+---------------------+----------------+
| 1 | 2010-08-20 12:00:00 | 01-A-04004 |
| 2 | 2010-08-20 13:00:00 | 02-B-01010 |
| 3 | 2010-08-20 15:00:00 | 03-C-02020 |
+------+---------------------+----------------+
--// Table: policies_property
+------+---------------------+------------------+
| id | date_issued | property_address |
+------+---------------------+------------------+
| 1 | 2010-08-20 14:00:00 | Oxford Street |
+------+---------------------+------------------+
类表继承的示例:一个超类,许多子类。每个子类id引用一个超类id。
--// Table: policies_super
+------+---------------------+
| id | date_issued |
+------+---------------------+
| 1 | 2010-08-20 12:00:00 |
| 2 | 2010-08-20 13:00:00 |
| 3 | 2010-08-20 14:00:00 |
| 4 | 2010-08-20 15:00:00 |
+------+---------------------+
--// Table: policies_motor
+------+----------------+
| id | vehicle_reg_no |
+------+----------------+
| 1 | 01-A-04004 |
| 2 | 02-B-01010 |
| 4 | 03-C-02020 |
+------+----------------+
--// Table: policies_property
+------+------------------+
| id | property_address |
+------+------------------+
| 3 | Oxford Street |
+------+------------------+
答案 0 :(得分:0)
我接下来不需要一次查询每个子类,而是所有查询一次只能在一个子类上(其中至少有9个子类)。
对我而言,这听起来是令人信服的理由让他们分开。不要认为'超类'方法是'更好的标准化'或'更多关系'等等。它们只是两个在理论上同样有效的设计选择;选择在实践中最有意义的那个。