规范化 SQL 表
我们可以进一步规范化这个 Sql 表吗 结构是 主键是ID、Date、NAME、Type
ID Date Name Type Value
-----------------------------------------------------
1 08/15/2010 Rating A+ 10
1 08/15/2010 Rating A- 10
1 08/15/2010 Composition MultipleChoice 33
1 08/15/2010 Composition YESNO 33
1 08/15/2010 Composition Fillin 33
1 08/16/2010 Rating A+ 30
1 08/16/2010 Rating A- 10
1 08/16/2010 Composition MultipleChoice 25
1 08/16/2010 Composition YESNO 50
1 08/16/2010 Composition Fillin 25
等
Can we furthur Normalize this Sql Table
Structue is
Primary key is ID,Date,NAme,Type
ID Date Name Type Value
-----------------------------------------------------
1 08/15/2010 Rating A+ 10
1 08/15/2010 Rating A- 10
1 08/15/2010 Composition MultipleChoice 33
1 08/15/2010 Composition YESNO 33
1 08/15/2010 Composition Fillin 33
1 08/16/2010 Rating A+ 30
1 08/16/2010 Rating A- 10
1 08/16/2010 Composition MultipleChoice 25
1 08/16/2010 Composition YESNO 50
1 08/16/2010 Composition Fillin 25
and so on
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这看起来可疑地像一个组合 EAV表和历史表。它的真正目的是什么？相关表是什么？
根据给定的有限信息，您可以通过将其转换为纯历史表来对其进行标准化。
Rating和Composition不应跨行拆分，而应位于命名得体的列中。像这样：.
这将允许更简单、更快：检查约束、索引和查询。
This looks suspiciously like a combination EAV table and history table. What is its true purpose? What are the associated tables?
Based on the limited information given, you would normalize it by turning it into a pure history table. The
RatingandCompositionshould not be split across rows but should be in decently-named columns. Something like so:.
This will allow for simpler and faster: Check constraints, indexes, and queries.
你可以这样做
You could do this
类型和名称是否会超出特定集合？您可以将它们分解为库表并引用它们。这是我唯一能想到的。
例如，如果您的类型始终是 A1、A2、B1、B2 和 C1，您可以将它们放入一个单独的表中，然后您可以拥有一个外键，而不是不断地将 A1 输入到数据库中转到引用 A1 行的类型表。
Are types and names going to be out of a specific set? You could break them out into lib tables and reference them. That's the only thing I can think of though.
For example, if your types are always going to just be A1, A2, B1, B2, and C1, you can go make those into a separate table, and then instead of constantly entering A1 into the database, you can have a foreign key off to the table of types that references A1's row.
我能看到的唯一明显的事情是将名称和类型分解为单独的表，但我不能明确地说，因为我不太确定它们实际代表什么。
The only obvious thing that I can see is breaking out Name and Type to separate tables, but I can't say definitely since I'm not quite sure what they actually represent.