我们目前处理这个问题的策略是为每个可能具有多个值的字段创建一个表。这将导致大量的表格(我们有很多不同的实体需要这样做),并且不太好维护。请问这是最佳策略吗?如果不是,有什么更好的方法呢?
如果您正在使用关系型数据库,那么您的建议基本上是唯一的方法。正常化理论将为您提供更多信息 - 关于它的维基百科文章非常好,尽管在进入更高级别的规范化水平时,它是一个棘手的理论主题,但例子大多是常识。
假设您有一个车辆表、一个颜色表和一个轮胎类型表(抱歉,这里用了英式拼写),您可能正在定义一个VehicleTyre和VehicleColour表,它作为相关表之间的连接。这种结构实际上非常健康。它不仅直接封装了您想要的信息,而且还让您以自然的方式捕捉诸如哪个轮胎是哪个(例如前左侧是Bridgestone 275/35-18)或汽车涂成红色的程度(例如在VehicleColour表上使用百分比字段)等信息。
您可能希望对车辆类型实体进行建模,以控制有多少个轮胎。虽然这不是从系统中获取工作SELECT查询所必需的,但在用户界面和确定要插入到表中的轮胎数量方面,它可能会非常有用。
我的公司有很多基于这个原则的模式 - 实际上,我们的对象关系框架会自动创建它们来管理多对多关系(有时甚至是一对多关系,这取决于我们如何建模)。我们的几个应用程序有超过150个实体和100多个连接表。除了一些表名令人讨厌地长之外,没有性能问题,也没有对数据可管理性的实质性影响。
这真的取决于变量本身是否只有一个变量(例如:您可以拥有一组相同类型的可变数量的轮胎,或者一组可变类型的固定数量的轮胎)。
由于您似乎需要具有多个变量(例如,每个轮胎都有特定的类型,且轮胎数量可变),我恐怕最好的解决方案是为您希望自定义的汽车的每个特定区域都有特定的表格。
如果您有一些字段只需在一组值之间进行选择(例如,2、4或6个窗户),则可以简单地使用枚举或使用用户定义域定义新的字段类型(取决于您使用的DBMS)。
你目前的策略是正确的。你正在跟踪很多种数据,所以你需要很多表格。这就是现实。数据库管理系统有抱怨吗?