我看到了一些不寻常的数据库设计，需要一些帮助来理解其中的挑战。
设计是这样的
1.数据库为Postgres
1.人力资源应用程序所需的所有数据--包括员工数据、时间表、发票等都存储在一个表中
1.该表包含EntityType、ID、Data(Jsonb)列。该表按实体类型进行分区。
将所有数据放到一个带有分区的表中，这是一个好的设计吗？
我们将面临哪些挑战？
我们每周会看到50万张新唱片。
我看到了一些不寻常的数据库设计，需要一些帮助来理解其中的挑战。
设计是这样的
1.数据库为Postgres
1.人力资源应用程序所需的所有数据--包括员工数据、时间表、发票等都存储在一个表中
1.该表包含EntityType、ID、Data(Jsonb)列。该表按实体类型进行分区。
将所有数据放到一个带有分区的表中，这是一个好的设计吗？
我们将面临哪些挑战？
我们每周会看到50万张新唱片。
1条答案
按热度按时间kwvwclae1#
这种模式称为EAV(实体属性值)，有时称为OpenSchema，但在数据库反模式中也称为数据库，在一些博客文章中称为EAVil模式。人们之所以倾向于使用它，是因为它在扩展模式方面提供了灵活性。
您现在插入的行数可能已经或很快会导致检索数据的严重性能问题，尽管我还没有尝试分区。尽管如此，我仍然相信这些EAV不像常规规范化模式那样可伸缩。
除了在EAV模式上编写查询要困难得多之外，您还会使所有值都是无类型的(除非在这方面花费很大的努力)、不可索引、数据约束将更难或不可能，因此数据完整性面临风险(年龄：-30岁)等等。
如果您想要一个很好的概述和好的建议，请阅读Bill Karwin的书《SQL反模式》，他写了几页关于EAV的主题。此外，甲骨文的Tom Kyte是反对EAV的强烈倡导者，还有许多其他人，他们的批评是站得住脚的。关系数据库不适合这种模式，您应该使用普通表。