【问题标题】:Storing Allowed Websites Per User in Postgres在 Postgres 中存储每个用户允许的网站
【发布时间】:2011-03-19 16:50:10
【问题描述】:

我的 Postgres 数据库中有一个用户表。在我的应用程序中,用户可以拥有各种允许的网站。我的问题是:哪个磁盘空间更有效,用户和 url 之间存在多对多关系,或者将数组以 JSON 格式存储在 User 表的列中。基本上,postgres 使用多少空间来存储表头。

谢谢。

【问题讨论】:

  • 一个完全有效的理论问题,postgresql 存储它的值的​​方式(查看源或原始数据文件是一种选择),但如果您非常关心这种关系的磁盘空间(而不是性能/其他),并且用户关系的数量不到几亿,你有更紧迫的问题。
  • 我刚读了一本关于扩展 Web 应用程序的书。由于我正在开发一个新的 Web 应用程序,我想我不妨在设计时考虑到可扩展性。
  • @Max:如果设计意味着过早优化,请不要考虑可扩展性。如果您认为某些东西很慢,请对其进行基准测试。如果它真的很慢,那么只有在那时你才应该优化它,并且只有当它是最慢的部分才能从优化中获得最大收益。

标签: sql json postgresql


【解决方案1】:

磁盘空间效率更高,在用户和 url 之间具有多对多关系,或者将数组以 JSON 格式存储在 User 表的列中。

更新多对多关系意味着一条 UPDATE(和/或 DELETE?)语句。

更新存储在数据库表中的 JSON 数组意味着:

  1. 选择数据以将其从数据库中取出到应用程序
  2. 在应用程序中处理数据
  3. UPDATE 语句将更新后的 JSON 数组写回到表中

哪个对您来说更简单/更高效?

【讨论】:

  • Postgres 有一个原生数组类型——它不涉及太多的应用程序操作。 (不是说数组方法更好,我同意多对多。)
  • @rfusca:我试图找出 Postgre 为 VARCHAR 分配了多少字节 - 你有链接吗?
  • 这里有一段话讲了一点。它有点难以计算,因为 postgres 会自动压缩长字符串。 postgresql.org/docs/current/static/datatype-character.html
猜你喜欢
  • 2011-02-06
  • 1970-01-01
  • 2016-04-23
  • 2016-01-29
  • 2012-06-02
  • 2019-05-26
  • 2014-11-22
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多