使用PostgreSQL将单个条目转换为数组

我有3个数据表。表A、AC和C。表AC仅使用外键将A和C连接在一起。当前，AC中的所有行都是创建这些连接的单个条目。因此，我在这件事上的问题是，是否有必要将AC中的所有单个条目转换为每一个条目对应的一行

A和C之间的连接是一对多的，因此数组长度基本上是1..x。表AC中每个A条目的平均条目数量约为6，因此如果将其更改为数组，则会显著减少AC中的条目

或者我应该删除AC，而只是将FK字段添加到A表中

在本用例中使用阵列时，陷阱在哪里？我是否必须在数组中使用JSON样式的条目：['blah'，'blah2'，'blah3']

下面的示例解释了数据库的结构，而值是假的：

Table A
|   id  |   name    |
---------------------
|   1   |   John    |
|   2   |   Jim     |
|   3   |   Joe     |


Table AC
|   id  |   id_a    |   id_c    |
---------------------------------
|   1   |   1       |   1       |
|   2   |   1       |   4       |
|   3   |   2       |   2       |
|   4   |   3       |   3       |
|   5   |   3       |   1       |


Table C
|   id  |   name    |
---------------------
|   1   |   Pie     |
|   2   |   Cake    |
|   3   |   Burger  |
|   4   |   Ice     |

---

把像than这样的东西放在一个数组中几乎没有意义。首先，也是最重要的一点，您失去了定义外键的能力。当从C中删除东西时，事情也变得非常混乱。当你真的，真的需要去规范化时，使用数组比使用逗号分隔的列表要好得多，但是：它的所有缺点都是去规范化的。让我们假设我有一个很棒的控制器，当一个条目从C中删除时，它能处理所有必要的操作。在这种情况下，它的效率还会显著提高吗？虽然我理解你对逗号分隔列表的担忧，但我会坚持使用纯数组。你的优秀控制器将无法保证数据库的一致性。您无法在应用程序层可靠地强制执行引用完整性。另外：经验表明，几乎没有任何重要的数据库只能由一个应用程序访问，而且数据库的寿命通常比应用程序长得多。不幸的是，这是一个真实的事实。如果我将自动行为构建到数据库本身，而不是应用程序控制器中，会怎么样？在9.4开发系列中，外键阵列已针对PostgreSQL进行了测试，但该修补程序的性能非常差，因此未被接受。事实证明，可靠地检查数组中的外键是很困难的。我建议阅读关于pgsql黑客的讨论历史。真的，不要重新发明这个轮子。除非你有强烈的需求，否则要让事情正常化。