数据建模。如何建模数百个相关字段，1:n 或作为一个 table？
Data modelling. How to model hundreds of dependent fields, 1:n or as one table?
我必须存储带有累进累进 运行 成本的租赁汽车，例如：
主要数据：
Id: 123
Model: Ford Transit
yom: 2013
毕业变量运行 成本：
kilometers/year utilities tires service misc
10,000 80 400 50 30
12,000 100 400 55 35
14,000 120 400 60 40
...
100,000 500 1,500 150 100
因此，在 10,000 到 100,000 的范围内，以 2,000 为步长和 4 种不同的成本类型，这将产生 50 x 4 = 200 个数据字段。
是将其建模为 1:n 关系更好，还是我的汽车中有超过 200 列是否可以 table (MySql)？存在哪些优点和缺点？
在 1:n 的情况下，每当输入新的汽车记录时，触发器在可变成本 table 中创建 200 个字段是否有意义？
提前感谢任何类型的提示
您可以使用具有预填充查找表（右侧）的数据模型。然后将该维护应用于实际车辆（左侧）
So with a scale of 10,000 to 100,000 in steps of 2,000 and 4 different cost types, this results in 50 x 4 = 200 data fields.
是的。规范化后，每条记录的 200 个字段将转换为每个规范化行的 4 列。
Is it better to model this as a 1:n relation or is it ok to have more than 200 columns in my car table (MySql)?
好吧，如果你考虑的是关系，它是一个1::n关系。
永远不会接受table在数据库中实现非规范化记录（例如，在您的情况下，200 个字段之一）。
What pros and cons do exist?
我不能在这里提供教程，但一般来说，规范化行具有 (a) 关系完整性，(b) 关系能力 [您会注意到以减少连接的形式]，(c) 关系速度(d) 易于扩展 [addition/change 到数据库]，以及 (e) 易于编码。 None 其中非规范化记录提供，它们提供相反的结果。
In case of 1:n, would a trigger make sense to create the 200 fields in the variable costs table whenever a new car record is entered?
一般来说，关系数据库不需要触发器。它们仅在需要做奇怪的事情时才需要，而奇怪的事情是不规范化数据的结果。
在您的情况下，添加的新车的 200 个值是未知的，因此触发器无论如何都不起作用。
不，在 ACID 事务中正确执行，当用户添加新车时，每公里步长填充四列。您可能有 4 个默认值自动填充屏幕上的字段，但在用户点击“添加”按钮之前不应将其保存到数据库中..
数据模型
这是您需要的数据模型。
我已经对数据进行了归一化处理，没有解释步骤或过程，这就是最终结果。
- 例如。
Ford Transit 不是原子的，我通过将 Manufacturer 和 Model. 分开使它成为原子的
Mandatory/Optional 费用：
如果每Maintenance（Kilometre步）行出现四个成本字段，则需要右边的模型
如果任何成本字段是可选的，则您需要左侧的模型。我假设 Service 是强制性的，即。每进入一公里就会出现。
我给了你关系键，因此给了你关系完整性。如果您不使用复合键，您将失去这种完整性。例如：
一个Model（eg.Transit）不是独立存在的，它只存在于Manufacturer（eg.Ford的上下文中]).
一个ModelYear（eg.2013）不是独立存在的，它只存在于Model（eg.Ford Transit的上下文中]).
如果您认为它们太宽，您可以替换名称代码。
The Maintenance table 需要一个简单的 CHECK 约束来确保 Kilometre 步骤以 2000 为模。
那是一个IDEF1X模型。 IDEF1X 是关系数据库建模的标准。请注意，每一个小滴答声；缺口;并做标记；鱼尾纹；实线与虚线；方角与圆角；意味着非常具体和重要的事情。参考IDEF1X Notation。如果您不理解符号，您将无法理解或工作模型。
记录编号
请注意，如今许多人不了解如何创建具有唯一行的关系 table，正如 关系模型 所要求的那样。他们创建文件，通常每个文件都有一个记录 ID，并允许大量重复。请阅读 ，从顶部到 False Teachers。并尝试其中给出和链接的代码。
警告
Zohar:
I would also suggest a lookup table for car models, so that each row in the cars table would have a model id instead of the model name.
这类建议来自于那些阅读过假教师的书籍，并在没有任何实际知识或经验的情况下应用并提出建议的人。它让每个人都停留在 1970'2 之前的 ISAM 记录归档系统中，同时认为他们拥有 "relational database"。
他们根本不知道他们所缺少的关系完整性、力量和速度。如果有人提出问题，我会提供答案。不在这里，这个答案是完整的。
我必须存储带有累进累进 运行 成本的租赁汽车，例如：
主要数据：
Id: 123
Model: Ford Transit
yom: 2013
毕业变量运行 成本：
kilometers/year utilities tires service misc
10,000 80 400 50 30
12,000 100 400 55 35
14,000 120 400 60 40
...
100,000 500 1,500 150 100
因此，在 10,000 到 100,000 的范围内，以 2,000 为步长和 4 种不同的成本类型，这将产生 50 x 4 = 200 个数据字段。
是将其建模为 1:n 关系更好，还是我的汽车中有超过 200 列是否可以 table (MySql)？存在哪些优点和缺点？
在 1:n 的情况下，每当输入新的汽车记录时，触发器在可变成本 table 中创建 200 个字段是否有意义？
提前感谢任何类型的提示
您可以使用具有预填充查找表（右侧）的数据模型。然后将该维护应用于实际车辆（左侧）
So with a scale of 10,000 to 100,000 in steps of 2,000 and 4 different cost types, this results in 50 x 4 = 200 data fields.
是的。规范化后，每条记录的 200 个字段将转换为每个规范化行的 4 列。
Is it better to model this as a 1:n relation or is it ok to have more than 200 columns in my car table (MySql)?
好吧，如果你考虑的是关系，它是一个1::n关系。
永远不会接受table在数据库中实现非规范化记录（例如，在您的情况下，200 个字段之一）。
What pros and cons do exist?
我不能在这里提供教程，但一般来说，规范化行具有 (a) 关系完整性，(b) 关系能力 [您会注意到以减少连接的形式]，(c) 关系速度(d) 易于扩展 [addition/change 到数据库]，以及 (e) 易于编码。 None 其中非规范化记录提供，它们提供相反的结果。
In case of 1:n, would a trigger make sense to create the 200 fields in the variable costs table whenever a new car record is entered?
一般来说，关系数据库不需要触发器。它们仅在需要做奇怪的事情时才需要，而奇怪的事情是不规范化数据的结果。
在您的情况下，添加的新车的 200 个值是未知的，因此触发器无论如何都不起作用。
不，在 ACID 事务中正确执行，当用户添加新车时，每公里步长填充四列。您可能有 4 个默认值自动填充屏幕上的字段，但在用户点击“添加”按钮之前不应将其保存到数据库中..
数据模型
这是您需要的数据模型。
我已经对数据进行了归一化处理，没有解释步骤或过程，这就是最终结果。
- 例如。
Ford Transit不是原子的，我通过将Manufacturer和Model. 分开使它成为原子的
- 例如。
Mandatory/Optional 费用：
如果每
Maintenance（Kilometre步）行出现四个成本字段，则需要右边的模型如果任何成本字段是可选的，则您需要左侧的模型。我假设 Service 是强制性的，即。每进入一公里就会出现。
我给了你关系键，因此给了你关系完整性。如果您不使用复合键，您将失去这种完整性。例如：
一个
Model（eg.Transit）不是独立存在的，它只存在于Manufacturer（eg.Ford的上下文中]).一个
ModelYear（eg.2013）不是独立存在的，它只存在于Model（eg.Ford Transit的上下文中]).如果您认为它们太宽，您可以替换名称代码。
The Maintenancetable 需要一个简单的CHECK约束来确保Kilometre步骤以 2000 为模。
那是一个IDEF1X模型。 IDEF1X 是关系数据库建模的标准。请注意，每一个小滴答声；缺口;并做标记；鱼尾纹；实线与虚线；方角与圆角；意味着非常具体和重要的事情。参考IDEF1X Notation。如果您不理解符号，您将无法理解或工作模型。
记录编号
请注意，如今许多人不了解如何创建具有唯一行的关系 table，正如 关系模型 所要求的那样。他们创建文件，通常每个文件都有一个记录 ID，并允许大量重复。请阅读
警告
Zohar:
I would also suggest a lookup table for car models, so that each row in the cars table would have a model id instead of the model name.
这类建议来自于那些阅读过假教师的书籍，并在没有任何实际知识或经验的情况下应用并提出建议的人。它让每个人都停留在 1970'2 之前的 ISAM 记录归档系统中，同时认为他们拥有 "relational database"。
他们根本不知道他们所缺少的关系完整性、力量和速度。如果有人提出问题，我会提供答案。不在这里，这个答案是完整的。