我应该为版本、代码库和可部署文件使用什么数据库表结构?

我对我的桌子结构有疑问,我想知道是否有更好的方法。

我有一个版本控制存储库(例如SVN)的小数据库,从中构建的包(例如Linux RPMS)以及它们的版本(例如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
...

这使我很容易看到,例如,给定包的有效版本是什么:我可以使用存储库ID加入版本表。但是,假设我想向该数据库添加一些信息,例如,指示哪些包版本已被批准发布。我当然需要一张新桌子:

package_version
- version_id
- package_id
- package_version_released
...

再说一次,我使用的键的性质对我的问题不是很重要,您可以想象数据列是“提升级别”,如果这有帮助的话。

当我意识到我的新表中的版本ID和包ID之间有着非常密切的关系时,我就会产生怀疑。它们必须共享相同的存储库ID。只有一小部分包/版本组合有效。所以我应该对这些列有某种约束,强制…

…我不知道,不知怎么的,它只是感觉不到。好像我包含了比我真正需要的更多的信息?我不知道如何解释我在这里的犹豫。我不知道我违反了哪种(如果有的话)正常形式,但我也找不到这种结构的模式的例子…不是专业的DBA,我不知道该去哪里找。

所以我问:我是不是太敏感了?