假设您有一个实体，例如您正在捕获其详细信息的车辆。您要捕捉的汽车被涂成红色、黑色和白色。前轮胎为普利司通 275/35-18，后轮胎为 325/30-19。有时您可能只有两个轮胎（是的，这将被视为摩托车，这是一种车辆），有时可能只有 18 个轮胎。然后有一些字段总是单值的，比如引擎大小（如果我们让我们的想象力疯狂，我们可以想到多引擎车辆，但我试图保持简单）。
我们目前处理这个问题的策略是为每个可以有多个值的字段创建一个表。这将产生大量的表（我们有一堆不同的实体有这个要求）并且闻起来有点难闻。这是最好的策略吗？如果不是，什么会更好？
如果您的应用有可能，您可能需要查看couchdb。
如果您使用的是关系数据库，那么您的建议几乎是唯一的方法。范式理论会给你更多关于它的信息——关于它的维基百科文章非常好，虽然有点沉重，因为当你进入更高的规范化水平时，它是一个棘手的理论主题。不过，这些例子大多是常识。
假设您有一个 Vehicle 表、一个 Color 表和一个 TyreType 表（对不起英国拼写），您大概定义了一个 VehicleTyre 和 VehicleColour 表，它充当相关表对之间的连接。这种结构实际上是相当健康的。它不仅直接封装了您想要的信息，还可以让您以自然的方式捕捉诸如哪个轮胎是哪个轮胎（例如左前是普利司通 275/35-18）或汽车有多少被涂成红色（例如VehicleColour 表中的百分比字段）。
您可能想要对可以控制轮胎数量的车辆类型实体进行建模。虽然这对于从系统中获取有效的 SELECT 查询不是必需的，但它可能在您的用户界面和确定要插入表中的轮胎数量方面都很有用。
我的公司有很多正是在这个基础上运行的模式——事实上，我们的对象关系框架会自动创建它们来管理多对多关系（有时甚至是一对多关系，具体取决于我们对它们的建模方式）。我们的几个应用程序有 150 多个实体和 100 多个这样的连接表。没有性能问题，也没有对数据的可管理性产生有意义的影响，除了一些表名长得令人讨厌。
您正在描述Star Schema。我认为在您的情况下这是相当标准的做法
编辑：实际上你的模式是从星模式稍微修改的，你使用每个维度表中事实表的主键来加入，所以你可以有多种油漆颜色等。无论哪种方式，我认为这是一个很好的处理方式与您的实体。您可以更进一步并规范化维度表，然后您将拥有一个雪花模式
看起来您可能正在查看称为Hierarchical Model的东西。
或者也许一个简单的 (attr, value) 对列表就可以了？
如果您使用的是 SQL Server，请不要害怕存储XML 数据类型。我发现它使这样的事情变得容易得多。
这实际上取决于变量本身是否只有一个变量（例如：您可以拥有可变数量的相同类型的轮胎，或者具有可变类型的固定数量的轮胎）。
由于您似乎需要有多个变量（例如，每个轮胎的特定类型，轮胎数量可变），恐怕最好的解决方案是为您希望定制的汽车的每个特定区域提供特定的表格。
如果您有一些字段只有一组值可供选择（例如，2、4 或 6 个窗口），您可以简单地使用枚举或使用用户定义的域定义新的字段类型（取决于您使用的 DBMS '正在使用）。
您当前的策略是正确的。您正在跟踪如此多类型的数据，因此您将需要大量表。就是这样。DBMS 在抱怨吗？