我正在创建服装店，因此我正在创建包含 2 种类型的图库功能：产品图库和 Lookbook 图库。产品图库只是单个产品的图片，而 Lookbook 图库是包含多个产品的图片。
到目前为止，我有一个简化的 UML 图，有点像这样
我不确定如何将其转换为 MySQL 表。我试过了，我想出了这样的东西
但这对我来说似乎有点矫枉过正，而且闻起来很有趣。在我的情况下，最佳做法是什么？我是在正确的轨道上还是我错了？
【问题讨论】：
标签： mysql database-design database-schema
我不知道这方面的“最佳实践”是什么，您可以使用 NO-SQL 数据库，或者如果您使用关系数据库，您可以只使用 3 个表格、画廊、图片和产品。
一个画廊可以包含许多图片
一张图片可以包含许多产品。
画廊类型之间的区别仅包含在一个属性中。
【讨论】：
首先考虑继承是否是实现所需行为的最佳方式。一般最好是prefer composition over inheritance。从你的图表我会说你真的不需要继承来解决你的问题。
如果您确实需要实现继承，那么您可以使用多种策略。寻找一个对象关系映射器是一个非常好的主意，因为一个好的映射器可以使以下策略的实现变得更加容易。如果您使用 .NET，那么 NHibernate 或 Entity Framework 是不错的选择。对于 Java，Hibernate 很不错。
每个类层次结构的表
在这里，您将为整个类层次结构创建一个表。这是最有意义的 当层次结构中的类都共享许多列时。您需要添加一个“鉴别器”列，以便您可以识别每行属于哪个子类。在您的示例中，您将拥有
我会说这种策略对您来说最有意义，因为您的子类之间似乎没有很多不同的列。
每个子类的表
在此示例中，您将为每个子类创建一个表。当继承层次结构中的类不共享许多公共列时，这是最有意义的。
所以你会有这样的表格：
每个班级的表格
这是您图表中的策略。就像每个子类的表一样，当每个子类都有不同的列时，这很有用。与 table-per-subclass 相比的优点是更容易在一个大连接中查询整个类层次结构，缺点是您最终会得到很多表。
【讨论】：
该数据库架构看起来注定要失败。定义模式时最重要的事情是从问题的名词和动词开始。用文字描述你的环境是什么样的。有哪些实体？实体如何相互交互？例如，“画廊有图片”。仅此声明就告诉您画廊和图片之间存在关联。
一旦你想出了你的名词-动词关联，你就可以开始展示实体，例如“画廊”和“图片”。画廊和图片之间是一对一的关系，还是一个画廊对多张图片？
思考这些问题，并在此处查看一些基本的设计技巧：http://msdn.microsoft.com/en-us/library/b42dwsa3(v=vs.71).aspx
【讨论】：