Nie, przechowywanie FK w tablicy nigdy nie jest dobrym pomysłem dla tabel ogólnego przeznaczenia. Przede wszystkim jest fakt, o którym wspomniałeś wcześniej:Ograniczenia klucza obcego dla elementów tablicy nie są (jeszcze) zaimplementowane. Samo to powinno unieważnić ten pomysł.
Podjęto próbę zaimplementowania funkcji dla Postgres 9.3, która została zatrzymana przez poważne problemy z wydajnością. Zobacz ten wątek na temat hakerów pgsql.
Ponadto, chociaż wydajność odczytu można poprawić za pomocą tablic w niektórych przypadkach użycia, wydajność zapisu spada. Pomyśl o tym:aby wstawić, zaktualizować lub usunąć pojedynczy element z długiej tablicy, musisz teraz napisać nową wersję wiersza z całą tablicą dla każdego przeniesionego elementu. Widzę też poważną rywalizację o blokadę.
Jeśli Twój stół jest tylko do odczytu , pomysł zaczyna nabierać sensu. Ale wtedy rozważyłbym widok zmaterializowany ze zdenormalizowanymi tablicami na górze znormalizowanej implementacji wiele do wielu:
Będąc przy tym, MV może zawierać wszystkie tabele złączeń i tworzyć jedną płaską tabelę, aby uzyskać jeszcze lepszą wydajność odczytu (dla typowych przypadków użycia). W ten sposób uzyskasz integralność referencyjną i dobra wydajność odczytu (i zapisu) - kosztem kosztów ogólnych i dodatkowej pamięci do zarządzania MV.
