Postgres db design Normalize tables or Use Array Columns

亡梦爱人 提交于 2021-02-17 07:03:25

问题


Newbie trying to figure out the best way to design a Postgres db for the following use case scenario.

There is an Account table for the business customers and there is a contacts table with a column relationship.

account.pk_id, ….

contacts.pk_id, contacts.fk_accountid …

Thousands of different businesses in the Accounts table will be storing millions of contacts each in the Contacts table.

Each contact record will over time belong to between 1 and 100 different categories, lists and products.

If I use a classic sql master/child relationship I potentially end up with millions and millions of rows in tables such as contacts_categories, contacts_lists and contacts_products which would reference from Categories, Lists & Products tables.

Alternatively, I could store the related keys ( uuid’s) for categories, lists and products in 3 character varying arrays[] columns in the contact record row. This would eliminate the need for the contacts_categories, contacts_lists and contacts_products tables that would be quite large.

With tools like Select unnest, array_append() and the array index options it seems like a smart solution but am curious to know if it is better to stick to normalized relations and more tables and row counts for performance and / or storage memory / cost.

Anybody tried this before ?


回答1:


Too many people have tried that, and it is a bad idea. Many of your queries, particularly joins, will become complicated and slow. Besides, you won't be able to have foreign key constraints to guarantee data integrity.

Relational databases are good at coping with millions of rows in a table. Keep your schema normalized.



来源:https://stackoverflow.com/questions/65237810/postgres-db-design-normalize-tables-or-use-array-columns

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!