数据库规范化是否正确？
我正在使用 mysql 数据库，有两个表 serviceTypeDetails、validateConfig。
serviceTypeDetails validateConfig
---------------------- ------------------
servicetypeid(pk) servicetypeid(fk)
servicetypename fieldname
modeType
----------------------------------------------------
在 serviceTypeDetails 中，它有四种类型的服务，另一个表 validateconfig 包含与每个 servicetypeid 有关的 31 行。此架构是正确的。如果不正确，则需要进行哪些修改？
谢谢
I am using mysql databse,with two tables serviceTypeDetails,validateConfig.
serviceTypeDetails validateConfig
---------------------- ------------------
servicetypeid(pk) servicetypeid(fk)
servicetypename fieldname
modeType
----------------------------------------------------
In serviceTypeDetails,it's having four types of services and another table validateconfig contain 31 row with respect to each servicetypeid.this schema is correct.if not then what modification it required?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，您使用的架构正确。这在 serviceTypeDetails 和 validateConfig 之间建立了一对多关系模型，因此可以附加更多validateConfig记录每个 serviceTypeDetails 记录。
Yes, you're using the schema right. This models a one-to-many relationship between serviceTypeDetails and validateConfig, so there can be more validateConfig records attached to each serviceTypeDetails record.
我只会在 validateConfig 表中包含一个复合主键，显然将 FK 保留在 servicetypeid 中。我想 {servicetypeid, fildname} 有效。
I only would include a composite primary key in the validateConfig table, obviously keeping the FK in servicetypeid. I suppose {servicetypeid, fildname} works.
如果不知道数据模型在话语域中应该代表什么、它应该执行什么依赖关系和业务规则等，没有人可以说数据模型是否“正确”。
我们可以确定的是 validateConfig您的示例中似乎没有任何候选键。如果是这种情况，那么我建议你解决这个问题。
No one can say whether a data model is "correct" or not without knowing what it is supposed to represent in the domain of discourse, what dependencies and business rules it is supposed to enforce, etc.
What we can be sure of is that validateConfig appears not to have any candidate keys in your example. If that is the case then I suggest you fix that.