Не, съхраняването на FK в масив никога не е добра идея за таблици с общо предназначение. Първо и най-важното, има факта, който споменахте мимоходом:Ограниченията на външния ключ за елементите на масива не са внедрени (все още). Само това би трябвало да анулира идеята.
Имаше опит за внедряване на функцията за Postgres 9.3, който беше спрян поради сериозни проблеми с производителността. Вижте тази тема за pgsql-hackers.
Освен това, докато производителността при четене може да бъде подобрена с масиви за определени случаи на употреба, производителността при запис пада рязко. Помислете за това:За да вмъкнете, актуализирате или изтриете единичен елемент от дълъг масив, сега трябва да напишете нова версия на ред с целия масив за всеки подреден елемент. Виждам и сериозен спор за заключване.
Ако вашата таблица е само за четене , идеята започва да има повече смисъл. Но тогава бих обмислил материализиран изглед с денормализирани масиви отгоре на нормализирана реализация много към много:
Докато е в това, MV може да включва всички таблици за свързване и да произвежда една плоска таблица за още по-добра производителност при четене (за типични случаи на употреба). По този начин получавате референтна цялост и добра производителност при четене (и запис) - на цената на режийните разходи и допълнителното хранилище за управление на MV.
