Não, armazenar FKs em uma matriz nunca é uma boa ideia para tabelas de uso geral. Em primeiro lugar, há o fato que você mencionou de passagem:Restrições de chave estrangeira para elementos de matriz não foram implementadas (ainda). Isso por si só deve anular a idéia.
Houve uma tentativa de implementar o recurso para o Postgres 9.3 que foi interrompido por sérios problemas de desempenho. Veja este tópico em pgsql-hackers.
Além disso, embora o desempenho de leitura possa ser aprimorado com arrays para determinados casos de uso, o desempenho de gravação despenca. Pense nisso:para inserir, atualizar ou excluir um único elemento de um array longo, agora você precisa escrever uma nova versão de linha com o array inteiro para cada elemento canged. E vejo uma séria contenção de bloqueio à frente também.
Se sua tabela for somente leitura , a ideia começa a fazer mais sentido. Mas então eu consideraria uma visualização materializada com arrays desnormalizados no topo de uma implementação de muitos para muitos normalizada:
Enquanto isso, o MV pode incluir todas as tabelas de junção e produzir uma tabela plana para um desempenho de leitura ainda melhor (para casos de uso típicos). Dessa forma, você obtém integridade referencial e bom desempenho de leitura (e gravação) - ao custo da sobrecarga e armazenamento adicional para gerenciar o MV.
