1

我正在创建服装店，因此我正在创建包含 2 种类型的图库功能：产品图库和外观图库。产品图库只是单个产品的图片，而外观图库是包含多个产品的图片。

到目前为止，我有一个简化的 UML 图，有点像这样

画廊类 UML 图

我不确定如何将其转换为 MySQL 表。我试过了，我想出了这样的东西

图库数据库UML图

但这对我来说似乎有点矫枉过正，而且闻起来很有趣。在我的情况下，最佳做法是什么？我是在正确的轨道上还是我错了？

4

3 回答 3

2

我不知道这方面的“最佳实践”是什么，您可以使用 NO-SQL 数据库，或者如果您使用关系数据库，您可以只使用 3 个表格、画廊、图片和产品。

一个画廊可以包含许多图片

一张图片可以包含许多产品。

画廊类型之间的区别仅包含在一个属性中。

于 2013-03-09T03:03:41.483 回答
2

首先考虑继承是否是实现所需行为的最佳方式。通常，最好选择组合而不是继承。从你的图表我会说你真的不需要继承来解决你的问题。

如果您确实需要实现继承，那么您可以使用多种策略。寻找一个对象关系映射器是一个非常好的主意，因为一个好的映射器可以使以下策略的实现变得更加容易。如果您使用 .NET，那么NHibernate或Entity Framework是不错的选择。对于 Java ， Hibernate非常好。

每个类层次结构的表

在这里，您将为整个类层次结构创建一个表。当层次结构中的类都共享许多列时，这是最有意义的。您需要添加一个“鉴别器”列，以便您可以识别每行属于哪个子类。在您的示例中，您将拥有

  • 画廊
  • 图片

我想说这种策略对您来说最有意义，因为您的子类之间似乎没有很多不同的列。

每个子类的表

在此示例中，您将为每个子类创建一个表。当继承层次结构中的类不共享许多公共列时，这是最有意义的。

所以你会有这样的表：

  • 产品图库
  • 日志_画廊
  • 产品图片
  • 日志_图片

每班表

这是您图表中的策略。就像每个子类的表一样，当每个子类都有不同的列时，这很有用。相对于每个子类的表的优点是更容易在一个大连接中查询整个类层次结构，缺点是您最终会得到很多表。

于 2013-03-09T03:12:06.180 回答
0

该数据库模式看起来注定要失败。定义模式时最重要的事情是从问题的名词和动词开始。用文字描述你的环境是什么样的。有哪些实体？实体如何相互交互？例如，“画廊有图片”。仅此声明就告诉您画廊和图片之间存在关联。

一旦你想出了你的名词-动词关联，你就可以开始说明诸如“画廊”和“图片”之类的实体。画廊和图片之间是一对一的关系，还是一个画廊对许多图片？

考虑这些事情，并在这里查看一些基本的设计技巧：http: //msdn.microsoft.com/en-us/library/b42dwsa3 (v=vs.71).aspx

于 2013-03-09T03:04:16.577 回答