将所有数据存储在一张带有分区的postgres表中
我看到了一些不寻常的数据库设计，需要一些帮助来理解其中的挑战。
DB的设计是
- Postgres
- HR 应用程序所需的所有数据 - 来自员工数据、时间表、发票等都存储在单个表中
- 该表具有 EntityType、ID、Data (jsonb) 列。该表按实体类型分区。
将所有数据放入一张带有分区的表中是一种好的设计吗？
我们将面临哪些挑战？
我们每周都会查看 50 万条新记录。
I saw a bit of an unusual database design and need some help understanding the challenges.
The design is
- DB is Postgres
- All the data needed for a HR application - right from Employee data , Timesheet , Invoice etc are stored in a single table
- The table has EntityType ,ID, Data ( jsonb ) columns . The table is partitioned by Entity Type.
Is putting all data into one table with a partition , good design ?
What challenges would we face ?
We are looking at half a million new records per week.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
此模式称为 EAV（实体属性值），有时称为 OpenSchema，但也称为数据库反模式中的数据库，以及在一些称为 EAVil 模式的博客文章中。人们倾向于使用它的原因是它在扩展模式方面提供的灵活性。
尽管我还没有尝试过分区，但您现在插入的行数可能已经或很快会导致检索数据时出现严重的性能问题。我仍然相信这些 EAV 的扩展性不如常规规范化模式。
除了在 EAV 模式上编写查询要困难得多之外，您还将所有值设为无类型（除非在这方面花费大量精力）、不可索引、数据约束将变得更加困难或不可能，因此数据完整性面临风险（年龄：-30） 如果您想要一个好的概述和好的建议，请阅读 Bill Karwins 的书《SQL Antipatterns》 ，
他写了几页关于 EAV 主题的文章。来自 Oracle 的 Tom Kyte 也是反对 EAV 的坚决拥护者，还有许多其他人，他们的批评是成立的。关系数据库不适合这种模式，您应该使用普通表。
This schema is called EAV (Entity Attribute Value), sometimes OpenSchema but also referred to as database in a database antipattern and in some blog post called EAVil schema. The reason people are tempted to use it is the flexibility it provides in extending the schema.
The number of rows you are inserting now will probably already or soon lead to serious performance problems retrieving data although i havent tried partitioning yet. Still i am convinced these EAVs dont scale as well as regular normalized schemas do.
Besides that queries are much harder to write on an EAV schema, you are making all values typeless (unless spending serious effort on this), non indexable, data constraints will be harder or impossible so data integrity is at risk (age: -30 ) etc etc.
If you want a good overview and a good advice read Bill Karwins' book SQL Antipatterns who writes several pages on the EAV subject. Also Tom Kyte from Oracle is a strong advocate against EAV and there are many others and their criticism holds up. Relational databases aren't suited for this kind of schema and you should use ordinary tables.