这个数据库方案是否合理？

Question

我需要帮助设计一个关于家具的PHP网站的数据库。

我有许多主要的类型，即应用领域。例如，办公室，户外等

我有皮革，布料等类别。

类别可以有多种类型。例如，布料可以在办公室和室外使用，例如，皮革不能在办公室使用。

每个类别都有一个名为“link”的字段，用于存储要在PHP页面菜单中显示的图像。

页面还有一个语言字段，用于显示不同语言的描述。

每个类别里面都有很多产品。某些类别与其他类别的产品具有相同的产品。

例如，

• 皮革可用于办公室制作皮椅。
• 布料可用于办公室制作布艺沙发。
• 但是皮革制品也可以在室外用来制作皮椅。

因此，同一产品可分为两类。

产品有许多模型图像（后视图，前视图，红色，黑色等）。

某些产品有一种技术图表，而其他产品则有另一种技术图表。例如，对于布椅，我不想显示宽度，而对于皮椅，我想要显示它是否易碎。技术图表也有不同的语言。

这是我的第一个大数据库。

下面的方案是否合适？或者我有一个概念缺陷？

（我添加了管理员，因此可以添加或取消产品或类别。）

为了澄清，我或多或少有这个：

• 类型：办公室，户外，汽车，船舶，合同，休闲
• 类别：皮革，比利皮革，布料，特卫强
• 产品：椅子，沙发，雨伞，桌子，盖子，......

每个产品只属于一个类别，但不仅仅用于类型。因此，例如，椅子可以仅制作皮革，但可以用于多种类型。

当我在我的网站上选择类型时，我想显示该类型的类别（类别可以在类型之间共享），然后我想选择该类别中的产品，看看可以使用哪种类型。

这是一个更新的数据库方案：

Answer 1

第一条规则，防止在数据库中输入类别两次或更多次。例如，输入可在室内和室外或两者中使用的皮革的照片和描述。假设你有一张“材料”表。无论您的家具材料是什么，我都会按如下方式分类：例如：输入{Enum（'室内'，'室外'，'室外'）}或数字格式，即{'1'，'2'，' 3'}你可以在你的评论部分，在表格内放置数字代表的数字。

然后从材料表中调用材料，而不是单独创建室内材料表和室外材料表。

Answer 2

第一次尝试也不错。 （顺便说一下，我以前在一家大型家具公司工作，所以这是一个罕见的案例，我实际上对实际数据有所了解，我试图在Stackoverflow上回答这个问题！）

我看到的最大问题是类型学和类别之间的关系。通过类别将产品链接到类型学，这意味着在我看来是相同的类别，例如“皮革”，需要多个记录，每个可能的类型一个。例如，如果您有皮革办公家具和皮革客厅家具，您将需要创建两个皮革记录。

我认为从产品到类别的FK和从产品到类型的单独的，不相关的FK更有意义。我猜你不需要强制执行限制，比如办公家具不能用柳条。您将不会有任何此类产品记录。但是，如果你确实需要强制执行此操作，那么我将在数据库中添加另一个连接类别和类型的表，它将编码所有可能的组合。也就是说，可能存在（办公室，皮革），（客厅，皮革），（办公室，织物），（室外，柳条）等的类别 - 类型记录。然后在添加产品记录之前，您验证组合在应用程序代码或触发器中是合法的。

我对通过Chart_type将技术图表链接到产品感到好奇。这张额外的桌子让你获得了什么？为什么不直接将它们链接到产品记录？我认为你只能有一种或其他图表类型，而不是两种？但是创建中间表并不会阻止创建两个记录。我认为您需要代码（或触发器）来表示如果存在，您不允许创建另一个或发出警告。当你正在寻找一个，只需在两个表上左边连接，看看你找到了哪个。如果在创建技术规范记录之前需要指定给定产品所需的产品，则在Product中输入一个字段以说明哪个是必需的。如果在实际创建一个之前未确定哪个，则记录的存在表明需要哪个并且您不需要任何其他字段。

我不清楚Category_type的用途。假设您需要将类别链接到类型学，为什么不直接链接它们？为什么桌子在中间？

顺便说一句，你的一些术语似乎很奇怪。这个术语是由客户决定的，还是您试图从另一种语言翻译？

因为“类别”你似乎意味着“物质”。为什么不用更加具体和明确的“材料”来称呼它？

通过“模型”，您似乎表示“图像”或“图片”。为什么不称呼它？ “Model”是“product”的同义词。 （有些公司会用它们来表示不同的东西，通常模型是给定产品的子类型，反之亦然。）

“类型学”一词的意思是“用于分配类型的系统”，而不是类型。您可以将此表称为“类型”。我一般不喜欢把事情称为“类型”，因为这是非常模糊的：当我们问什么“类型：家具是什么我们希望有人回答”卧室“，”皮革“，”殖民地“，”顶部质量“，”导入“，或任何其他几十种可能的分类？我个人称之为”设置“。

但是如果你正在翻译，也许原始名称很有意义，这是一个没有实际意义的点。