>上下文：用于个人学习目的的简单网络应用程序游戏，使用postgres。我可以随心所欲地设计它。
2 个表 1 个视图（还有其他不重要的表视图引用）
Table: Research
col: research_id (foreign key to an outside table)
col: category (integer foreign key to category table)
col: percent (integer)
constraint (unique combination of the three columns)
Table: Category
col: category_id (primary key auto inc)
col: name(varchar(255))
注意：此表的存在是为了捕获我想要在业务逻辑中进行的 4 类研究，我认为在数据库中硬编码为列不是最佳实践
View: Research_view
col: research_id (from research table)
col: foo1 (one of the categories from category table)
col: foo2 (etc...)
col: other cols from other joins
注释：具有适当使用上述表格的插入/更新/删除语句
我担心研究表本身就有资格称为"瘦桌子"（直到我刚刚在伊巴蒂斯曼宁的书中看到它才听说过这个词）。例如，其中的测试数据如下所示：
| research_id | percent | category |
| 1 | 25 | 1 |
| 1 | 25 | 2 |
| 1 | 25 | 3 |
| 1 | 25 | 4 |
| 2 | 20 | 1 |
| 2 | 30 | 2 |
| 2 | 25 | 3 |
| 2 | 25 | 4 |
1） 让表中的所有列共同定义唯一条目是否有意义？
2）这对你来说"闻起来"吗？
几个注意事项：
约束（三列的唯一组合）
具有包含单列主键的唯一约束是没有意义的。 包含该列将导致每一行都是唯一的。
notes: this table exists to capture the 4 categories of research I want in business logic and which I assume is not best practice to hardcode as columns in the db
如果研究项目/实体需要定义所有四个类别才能有效，则它们绝对应该是研究表中的列。 我无法从你的陈述中确切地判断情况是否如此，但如果孤立地看，你的假设是错误的。 让您的模型尽可能反映现实。
另一个因素是是否要求在部署后向系统添加其他类别。 类别是灵活还是固定，绝对应该影响设计。
1）将所有列放在一个表中是否有意义 定义唯一条目？
我会说这并不常见，但可以想象在某些情况下可能是合适的。
2）这对你来说"闻起来"吗？
没有更多细节很难说。
综上所述，如果目的是查看和添加具有所有四个类别的研究项目，我会（再次）考虑这四个类别是否是研究实体的语义属性。
作为一个随机示例，身高和体重等内容可能被视为人员的类别，但它们可能会平坦地存储在人员表中，而不是单独的表中。