我对我的桌面结构有疑问，我想知道是否有更好的方法。
我有一个用于版本控制存储库（例如SVN）的小数据库，由其构建的包（例如Linux RPM），以及其版本（例如1.2.3-4）。给定的存储库可能不会产生任何包或几个包，但如果给定存储库有多个包，那么该存储库的特定版本将指示代码库的单个“标记”。
特定版本的“字符串”可能用于在多个存储库中标记源代码的版本，但两个不同存储库的“1.0”之间可能没有关系。因此，如果包P和Q都来自repo R，那么P 1.0和Q 1.0都是从repo R的1.0标签构建的。但是如果包X来自repo Y，那么X 1.0与P 1.0没有关系。
在我的（简化）模型中，我有以下表格（x_id列是自动递增的代理键;如果你愿意，你可以假装我使用不同的主键，这不是很重要）：
repository
- repository_id
- repository_name (unique)
...
version
- version_id
- version_string (unique for a particular repository)
- repository_id
...
package
- package_id
- package_name (unique)
- repository_id
...
这使我很容易看到，例如，什么是给定包的有效版本：我可以使用repository_id与版本表连接。但是，假设我想向该数据库添加一些信息，例如，以指示哪些软件包版本已被批准发布。我当然需要一张新桌子：
package_version
- version_id
- package_id
- package_version_released
...
同样，我使用的密钥的性质对我的问题并不重要，你可以想象数据列是“promotion_level”或者其他东西，如果这有帮助的话。
当我意识到我的新表中的version_id和package_id之间存在非常密切的关系时，我的怀疑就出现了......他们必须共享相同的repository_id。只有一小部分包/版本组合有效。所以我应该对这些列有一些约束，强制执行......
......我不知道，不知何故感觉不对劲。就像我包含的信息比我真正需要的更多？我不知道如何在这里解释我的犹豫。我无法弄清楚我违反了哪种（如果有的话）正常形式，但我也找不到这种结构的架构示例......不是专业的DBA我不知道在哪里看。
所以我问：我只是过于敏感吗？
答案 0 :(得分：2)
可能你已经标准化了太多，拥有这种结构会不会更有意义：
repository
- repository_id
- repository_name (unique)
...
version
- version_id
- version_string (unique for a particular repository)
...
package
- package_id
- package_name (unique)
...
然后有一个包含有效版本的表以及它们是否已被释放：
package_version
- package_version_id
- repository_id
- version_id
- package_id
- package_version_released
...
因此，package_version表包含所有有效版本的所有组合，以及它们是否已被释放。
除非我在上面的解释中错过了一些内容......
答案 1 :(得分：0)
是的，我过于敏感了。特别是当我意识到一个包可以想象地随着时间的推移移动到不同的存储库（更改包表的内容），所以package_version表实际上没有额外的信息。事实上，它是必不可少的。