No, almacenar FK en una matriz nunca es una buena idea para tablas de propósito general. En primer lugar, está el hecho que mencionó al pasar:las restricciones de clave externa para los elementos de la matriz no están implementadas (todavía). Esto solo debería anular la idea.
Hubo un intento de implementar la función para Postgres 9.3 que se detuvo debido a problemas de rendimiento graves. Vea este hilo sobre pgsql-hackers.
Además, si bien el rendimiento de lectura se puede mejorar con arreglos para ciertos casos de uso, el rendimiento de escritura se desploma. Piénselo:para insertar, actualizar o eliminar un solo elemento de una matriz larga, ahora debe escribir una nueva versión de fila con la matriz completa para cada elemento cambiado. Y veo una seria disputa de bloqueo más adelante, también.
Si su tabla es solo lectura , la idea empieza a tener más sentido. Pero entonces consideraría una vista materializada con matrices desnormalizadas en la parte superior de una implementación normalizada de muchos a muchos:
Mientras está en eso, el MV puede incluir todas las tablas de unión y producir una tabla plana para un rendimiento de lectura aún mejor (para casos de uso típicos). De esta forma obtiene integridad referencial y buen rendimiento de lectura (y escritura), a costa de la sobrecarga y el almacenamiento adicional para administrar el MV.
