数据库关系方向及其表现

Question

我正在尝试为我的项目创建架构。结构非常简单，但至少有一些方法可以使用 Prisma 来实现。我的大多数同事都建议我采用想法 2，但我进行了一些性能测试，结果很奇怪。

想象一下我们有文件并且文件类型很多的情况，例如发票、停车罚款、租金账单等。 一份文档应该只有一个文档详细信息对象。

我想在这里使用组合方法：

文档表

ID	Document type (enum)	Invoice ID (fk)	Parking fine ID (fk)	Rent bill ID (fk)
1	"Invoice"	1	null	null
2	"Fine"	null	1	null
3	"Rent"	null	null	1

发票表

ID	Invoice number
1	QWERTY1234

停车罚款表

ID	Car number
1	ZXC123

租金账单表

ID	Aparatment number
1	54

如您所见，我们有一个标题表（文档表）和包含详细信息的表。

第二种方法：

文档表

ID	Document type (enum)
1	"Invoice"
2	"Fine"
3	"Rent"

发票表

ID	Invoice number	Document ID
1	QWERTY1234	1

停车罚款表

ID	Car number	Document ID
1	ZXC123	2

租金账单表

ID	Aparatment number	Document ID
1	54	3

从 Prisma 的角度和代码中的用法来看，这两种解决方案完全相同。我相信这只是关系方向。但是，我用 300k 文件、100k 发票、100k 罚款和 100k 租金为这两个数据库播种。

我尝试使用“findMany”功能并获取所有文档，包括文档详细信息。使用第一个模型，我能够在出现“无法连接到数据库”错误之前获取大约 80k 行，第二个模型只允许获取 30k 行。

从您的角度来看，哪种方法更有效？它们之间有什么区别吗？

提前感谢您的任何建议！

Answer 1

如果我错了，请纠正我，但您实际上是在询问关系的哪一侧应该存储外键。

我找到了关于 in a similar StackOverflow question 的一个很好的答案，上面写着：

简而言之，最好先确定父表（首先添加记录的表）并建立从父表到子表的关系，即使是一对一关系也是如此。

在您的情况下，“文档表”看起来像父表（将首先添加数据），因此将外键添加到 Invoice/Fine/Rent 表是有意义的（选项 2 ）。这也使表结构更加高效，因为“文档表”中没有n-1 null 外键列（如您的第一个选项中的情况）。

关于解释性能测试的注意事项：您运行的测试是否代表了您的实际工作流程？例如，应用程序通常会运行与您在测试本身中所做的完全相同类型的查询吗？如果是，那么也许选择选项 1 可能 是有意义的。但是，这是您必须进行调用的有意权衡。 在我看来我会警惕像这样过早地进行优化，除非我有理由认为这将成为未来的瓶颈。

这个答案中提到的大部分内容都是我的观点，我认为您的问题没有客观正确的答案。