SQL效率参数，添加列还是可通过查询解决？

我刚大学毕业，是软件开发的新员工。最近事情有点慢，所以给了我一个db任务。我的数据库技能仅限于使用Rails和Django的pet项目。所以，我对我最近的任务有点惊讶

我的经理要求我用“父”表对Person进行子分类，并在Person表中添加对其保管人的引用。当托管人（而非家长）是FormContact时，这有助于从家长到表单的转换

下面是我正在使用的sql db的简化模拟结构。如果我有权访问Visio，我会绘制关系表

我们有一个表“Person”和一个表“Form”。有一个表“FormContact”，它将一个人与一个表单关联，但并非所有人都与一个表单关联。有一个人际关系表（雇主、父母等）

我问，“为什么不能通过查询来处理这个问题？”回答很低效。（真的！？！）

因此，我问，“为什么不引用表单？这样会更有效，因为您不会使用来自孩子/监护人的引用来查询FormContacts表。”回答，这基本上会使家长成为FormContact。（很公平。）

我编写了一个查询，从非FormContact父级到窗体，并在生产服务器上进行了测试。响应时间是瞬时的。SOME_值是父对象的fk ID

SELECT FormID 
FROM FormContact 
WHERE FormContact.ContactID 
    IN (SELECT SourceContactID 
        FROM ContactRelationship
        WHERE (ContactRelationship.RelatedContactID = *SOME_VALUE*) 
            AND (ContactRelationship.Relationship = 'Parent'));

---

如果我是对的，“这是一个不必要的改变。”我应该怎么做，捍卫我的立场，还是应该向经理们的要求让步

---

如果我错了。我的错误是什么？有比经理的更好的解决方案吗？

首先，您的查询可能需要一些修改。尝试使用

连接，而不是子选择：

SELECT FormID

FROM FormContact fc

JOIN ContactRelationship cr on cr.SourceContactID = fc.ContactID 
                               and cr.Relationship = 'Parent'

WHERE cr.RelatedContactID = @parent_id

其次，您要处理的问题是规范化与性能。从纯度的角度来看，是的，您的解决方案是“更正确的”（因为您没有复制数据，这消除了复制数据中的差异导致冲突和异常行为的可能性），但纯标准化并不总是最明智的做法

规范化可能导致性能下降，尤其是在较大的数据集中。这些处罚必须与正常化带来的好处一起权衡，以确定哪一方“获胜”

话虽如此，我看不出再次加入
ParentID
列上的
Person
表（我假设您将添加该表）将如何比上面列出的联接提供性能提升，假设相关列已正确索引

如果上述查询对您有效，并且您进行了严格的性能测试以证明其有效性，请将其提交给您的经理并征求他的意见。因为你是刚从大学毕业的新人，所以在这件事上要非常愿意听从你经理的判断和愿望。未来会有更大的战斗要打。
你到底在问什么？你反对系统的哪一方面？我不明白SQL查询是如何低效的。尤其是像这样简单的。另外，我不知道创建子类和列（这将导致另一个SQL查询）如何更有效。两个查询之间的唯一区别是一个使用子查询，另一个使用fk id。您可以发布经理建议的查询/解决方案吗？我可能会建议加入，而不是内部的select声明。这里有一些关于大学刚毕业的新员工的建议。虽然你的解决方案可能会更好，但要注意如何与你的经理接洽。我发现有些经理非常自负（出于某种原因，这在这个领域很普遍），如果你拍他的脸说你的想法更好，即使是这样，他也可能不欣赏。你可以发布当前的表DDL和建议的表DDL吗？我喜欢这个答案。我可以使SQL查询适应实际的数据库和规范化的解释。性能信息丰富。此外，它还解决了经理问题。谢谢