我有一个数据库存储哈希值和一些关于哈希的数据，所有这些都在一个表中。其中一个字段是'job_id'，它是散列来自的作业的ID。
我试图解决的问题是，使用这种设计，哈希只能属于一个作业 - 实际上哈希可以在许多作业中发生，我想知道发生哈希的每个作业
我正在考虑这样做的方法是创建一个名为“Jobs”的新表，其中包含字段'job_id'，'job_name'和'hash_value'。当一批新数据插入到数据库中时，将在此处创建作业ID和名称，并且每个哈希都将在此处以及原始哈希表中进行，但在“作业”表中，它还将针对作业存储
我不喜欢这样，因为我会在表格之间复制哈希列。有没有更好的办法？我可以添加到哈希表但不能删除任何列，因为闭源软件依赖于它。哈希值是主键。它是MySQL，数据库存储了数百万条记录。提前谢谢！
答案 0 :(得分：1)
我试图解决的问题是，使用这种设计，哈希可以 只属于一个工作 - 实际上哈希可以在许多工作中发生，并且 我想知道发生哈希的每个工作。
我想这样做的方法是创建一个名为的新表 'Jobs'，字段'job_id'，'job_name'和'hash_value'。
只要你能也得到a）外键正确，b）级联“job_id”和“hash_value”，那应该没问题。
重复数据和冗余数据是关系建模中的技术术语。 技术术语意味着它们具有您在词典中找不到的含义。它们并不意味着“相同的值出现在多个表中”。 应该显而易见，因为如果用代理ID号替换值，那么这些ID号将出现在多个表中。
这些技术术语实际上是指“具有相同含义的相同值”。 （相关：Hugh Darwen's article用于谓词的定义和使用。）
用ID号替换文本可能有很好的实际原因，但没有理论上的理由这样做，并且规范化当然不需要它。 （没有“每一行都有一个ID号”的正常形式。）
答案 1 :(得分：1)
添加新的job表是可行的方法。这是表达一对多关系的规范性实践。
避免不必要的重复值是很好的。但在这种情况下，您并没有真正“复制”hash_value列;相反，您确实定义了job与以hash_value为主键的表格之间的关系。
通过向子表添加列来实现关系;该列包含父表的主键值。通常，我们也会在列上添加FOREIGN KEY约束。
答案 2 :(得分：0)
如果我正确地阅读了你的问题，那么你的设计存在根本性的缺陷，因为这两个事实：
随着数百万行/哈希，最终你会得到哈希冲突。
唯一合理的方法是将job_id作为主键，并在具有非唯一索引的列中进行哈希处理。找到给定哈希的作业将是直截了当的。