Question

我正在开发一个分类广告网站。而且我完全陷入数据库设计层面。广告只能分为1类。在我的数据库中，我有一个名为“ads”的表格，其中包含所有广告通用的列。

CREATE TABLE Ads (
AdID int not null,
AdDate datetime not null,
AdCategory int not null,
AdHeading varchar(255) not null,
AdText varchar(255) not null,
etc...
);

我也有很多类别。例如，在“汽车”类别中发布的广告具有其他列，如品牌，型号，颜色等。广告，张贴在“住房”中的列类似于住房类型，平方英尺。等等... 我做了类似的事情：

CREATE TABLE Cars (
AdID int not null,
CarMake varchar (255) not null,
CarModel varchar(255) not null,
...
);

CREATE TABLE Housing (
AdID int not null,
HousingType varchar (255) not null
...
);

AdId就是广告的外键。

但是，当我需要从广告中检索信息时，我必须查找所有这些附加表格，并检查广告中的AdId是否等于这些表格中的AdId。对于每个类别，我都需要一个新表。我最终会得到15张左右的桌子。我有一个想法，在广告表中有一个布尔列，如is_Cars，is_Housing等，但有15列，其中14将是NULL似乎是可怕的。有没有更好的方法来设计这个数据库？我需要我的数据库处于第3范式，这是最重要的要求。

Answer 1

不要过分担心 - 这是一个众所周知的困境，没有银子弹＆＃39;并且所有解决方案都有一些权衡。您的解决方案对我来说听起来不错，并且通常在行业中使用。如你提到的那样，它有JOINS（这是一个众所周知的规范化权衡），而且每个新产品类型都需要一个新的TABLE。从表面上看，表结构精确地反映了您的业务逻辑，它在存储方面具有可读性和高效性。

据我了解，您的其他建议是一个单独的表格，其中每一行都有一个＆＃34;类型＆＃34;指示 - 汽车，房屋等（顺便说一句，不需要多列，例如＆＃39; is_car＆＃39;，＆＃39; is_house＆＃39; - 单个列＆＃39;类型＆＃更简单39 ;,例如type = 1表示car，type = 2表示house等）。然后是多列，其中一些列用于某些产品类型。好吧，这里的优点是能够动态添加新类型（甚至是用户定义的类型）而无需更改数据库模式。也没有＆＃39;加入＆＃39;。在不利方面，你将存储＆amp;检索大量的＆＃39; null＆＃39;细胞，以及模式将不那么具有描述性：例如更难以设置约束＆＃34; carModel列不可为空＆＃34;，因为它可以用于房屋（你可以使用触发器，但它的可读性较差）。

我个人更喜欢第一种解决方案（当然取决于用例，但第一种解决方案是我的第一直觉）。在考虑权衡之后，我可以放心地使用它，例如理解我能够容忍那些JOINS作为可读和附件的付款。紧凑的架构。

Answer 2

一，您对类别和产品规格感到困惑。

二，你需要阅读表继承。

如果您不介意空值，请使用单表继承。所有＆＃34;类别＆＃34; （汽车，房屋......）进入一张桌子并且有一个＆＃34;类型＆＃34;列。

如果您不喜欢null，请使用Class Table Inheritance。使用指向类别外键的主键创建主表。为每个类型（汽车，房屋......）创建子表，其主键也是主表的外键。像Hibernate这样的ORM更容易实现。

数据库设计混乱

2 个答案: