假设我们有一个要捕获详细信息的类似车辆的实体。我们要捕获的汽车被漆成红色，黑色和白色。前轮胎是普利司通275 / 35-18，后轮胎是325 / 30-19. 有时我们可能只有两个轮胎(是的，这会被视为摩托车，是一种车辆)，有时可能会有18个可能完全不同的轮胎。还有一些领域总是像引擎大小那样是单值的(如果我们让我们的想像力发疯，我们可以想到多引擎车辆，但是我试图保持这种简单性)。

我们当前的处理策略是为每个可以具有多个值的字段创建一个表。这将产生大量的表(我们有许多与此要求不同的实体)，并且闻起来有点不好。这是最好的策略吗？如果不是，那会更好？

解决方案

回答

如果应用程序有可能，我们可能需要研究Sofadb。

回答

我们正在描述星型模式。我认为这在情况下是相当标准的做法

编辑：实际上，架构是从Star架构中稍作修改的，我们在每个维表中使用事实表的主键进行联接，以便可以使用多种绘制颜色等。无论哪种方式，我认为这都是一种很好的处理方式与实体。我们可以再进一步一步，对维度表进行规范化，然后获得一个Snowflake Schema

回答

似乎我们正在寻找一种称为"层次模型"的东西。

还是一个简单的(属性，值)对列表会起作用？

回答

如果我们使用的是SQL Server，请不要害怕存储XML数据类型。我发现它使这样的事情变得非常容易。

回答

这实际上取决于变量本身是否只有一个变量(例如：我们可以拥有可变数量的所有相同类型的轮胎，或者一组固定数量的可变类型的轮胎)。

由于我们似乎需要多个变量(例如，每个轮胎的特定类型，轮胎数量可变)，因此最好的解决方案是为我们要自定义的汽车的每个特定区域提供特定的表格。

如果有些字段仅具有一组要选择的值(例如2、4或者6个窗口)，则可以简单地使用枚举或者使用用户定义的域定义新的字段类型(取决于我们使用的DBMS正在使用)。

回答

如果我们使用的是关系数据库，那么建议几乎是唯一的方法。规范形式的理论将为我们提供更多有关它的信息，尽管关于Wikipedia的文章还不错，但其篇幅比较繁琐，只是因为进入较高的规范化水平时它是一个棘手的理论主题。这些例子通常是常识。

假设我们有一个Vehicle表，一个Color表和一个TyreType表(对不起，英式拼写)，那么我们将定义一个VehicleTyre和VehicleColour表，它们充当相关表对之间的联接。这种结构实际上非常健康。它不仅可以直接封装我们想要的信息，还可以让我们以自然的方式捕获诸如哪个轮胎是哪个轮胎(例如，左前是普利司通275 / 35-18)或者多少辆汽车被涂成红色(例如，带有一个轮胎)的信息。 VehicleColour表上的百分比字段)。

我们可能希望对可以控制轮胎数量的车辆类型实体进行建模。虽然从系统中退出有效的SELECT查询不是必需的，但它可能在用户界面和确定要插入表中的轮胎数量中都将很有用。

我的公司有很多模式都是在此基础上运行的，实际上我们的对象关系框架会自动创建它们来管理多对多关系(有时甚至是一对多关系，这取决于我们对它们的建模方式)。我们的几个应用程序拥有150多个实体，其中100多个联接表。没有性能问题，对数据的可管理性也没有任何有意义的影响，只是其中一些表名令人讨厌。

回答

我们当前的策略是正确的。我们正在跟踪多种数据，因此我们将需要大量表。就是这样。 DBMS在抱怨吗？