Non, stocker les FK dans un tableau n'est jamais une bonne idée pour les tables à usage général. Tout d'abord, il y a le fait que vous avez mentionné en passant :les contraintes de clé étrangère pour les éléments de tableau ne sont pas (encore) implémentées. Cela seul devrait annuler l'idée.
Il y a eu une tentative d'implémentation de la fonctionnalité pour Postgres 9.3 qui a été arrêtée par de graves problèmes de performances. Voir ce fil sur pgsql-hackers.
De plus, alors que les performances de lecture peuvent être améliorées avec des baies pour certains cas d'utilisation, les performances d'écriture chutent. Pensez-y :pour insérer, mettre à jour ou supprimer un seul élément d'un long tableau, vous devez maintenant écrire une nouvelle version de ligne avec le tableau entier pour chaque élément modifié. Et je prévois également de sérieux conflits de verrouillage.
Si votre tableau est en lecture seule , l'idée commence à avoir plus de sens. Mais alors je considérerais une vue matérialisée avec des tableaux dénormalisés en haut d'une implémentation plusieurs-à-plusieurs normalisée :
Pendant qu'il y est, le MV peut inclure toutes les tables de jointure et produire une table plate pour des performances de lecture encore meilleures (pour les cas d'utilisation typiques). De cette façon, vous obtenez l'intégrité référentielle et bonnes performances de lecture (et d'écriture) - au prix de la surcharge et du stockage supplémentaire pour la gestion de la MV.
