我正在做一件事 MySQL （通过prisma数据模型）的架构 Customer 电子商务环境中的实体。随着战场数量的激增（比如说，交战跟踪），我这里有两种可能的设计：
type Customer {
email: String! @unique
name: String
birthDate: DateTime
addresses: [Address!]!
...
productsVisited: [Product!]!
productsShared: [Product!]!
productsSearched: [Product!]!
...
}传递信息的字段或字段应被划分到各自的表中，并通过1:1的关系连接到上一个表中：
type Customer {
profile: CustomerProfile! @relation(name: "CustomerProfile", onDelete: CASCADE)
addresses: [Address!]!
...
productEngagements: ProductEngagement! @relation(name: "CustomerProductEngagements", onDelete: CASCADE)
...
}
type CustomerProfile {
customer: Customer! @relation(name: "CustomerProfile", onDelete: SET_NULL)
email: String! @unique
name: String
birthDate: DateTime
}
type ProductEngagement {
customer: Customer! @relation(name: "CustomerProductEngagements", onDelete: SET_NULL)
productsVisited: [Product!]!
productsShared: [Product!]!
productsSearched: [Product!]!
}问题：
设计的正确思维方式是什么？我现在被我的er图和直觉所驱使。通过使表的列数变细，我是否获得或失去了任何执行或灵活性优势？
在第二种方法中，查询是否必须为表联接做额外的工作？
抽象问题：
在不断发展的模式或性能标准下，一种方法肯定比另一种更好吗？或者，这只是品味的问题？
2条答案
按热度按时间uxh89sit1#
这两种方法肯定都会起作用，而且这在一定程度上取决于您的个人喜好和处理数据时希望使用的api。
使用您概述的第二种方法，prisma确实会为
CustomerProfile,ProductEngagement以及所有其他类型（一般来说，prisma会将数据模型中的所有类型定义Map到它们自己的表中）。所以，正如@rick james所指出的，可能在JOIN检索数据时需要执行的。设计的正确思维方式是什么？我现在是由我的er图驱动的。
这通常是一种有效的方法，因为prisma数据模型最终被Map到数据库。从这个意义上说，用er图来考虑应该是很好的。
另外请注意，prisma很快将支持embeded类型，它允许在prisma数据模型中定义一个类型，该类型没有自己的表，但数据存储在非嵌入类型的表中的json列中。在mongodb中使用prisma时，目前已经支持这一点，但在sql中还不支持。您可以在此功能请求中了解有关此主题的更多信息。
qvsjd97n2#
在rdbms中，很少有充分的理由将一个表按1:1的关系拆分为两个表。至
JOIN他们又在一起了SELECT这当然是可能的，但会增加一些开销、代码复杂性，并且会对性能造成轻微影响。也就是说，我（很少）遇到这样一种“垂直分割”有益的情况。
一个表中有“太多”列，拆分可以避免达到某些数据库限制(其他解决方案可能会更好地处理这种情况。）
有些柱子既笨重又很少使用。。。通过将它们移动到一个单独的表中
JOIN通常是避免的，而“笨重”的潜在性能冲击通常是避免的。您需要向一个巨大的表中添加一些列，但是
ALTER TABLE命令是如此昂贵（想想，停机时间），以至于你不顾一切地想办法避免它。。。这样一张单独的table很快、很容易等（但是，当然，也有需要的不便等）JOIN.)有一组列很少出现在表中。。。在拆分这些列之前，您打算用
NULLs（一件有效的事情）。但是在将它们分开之后，在另一个表中就没有行了。然后你用一个LEFT JOIN从而重建NULLs凭空而来。