мимопроходомНадо сделать следующий констрейнт
Есть таблица parent есть таблица child. Они связанны между собой отношением многие ко многими, т.к. один парент имеет несколько child, возможно вхождение одних и тех же child в разные parent.

Надо установить констрейнт на то, чтобы в БД небыло двух разных parent с одинаковой номенкулатурой child. Ничего лучше чем добавить в парента текстовое поле и перечислить в нем PK детей в алфовитном порядке через запятую и наложить на это поле юник в голову не приходит что есть явное нарушение 1НФ.

Надо как в школе учат сделать третью таблицу, которая связывает parent и child. А далее как Вы и предложили организовать вспомогательный "индекс" для целей ускорения. Это может быть цепочка id, но в общем случае это м.б. любая функция, которая дает уникальное значение для каждого уникального набора children. Список не очень хорошо из-за переменной длины, но зато его легко вычислять, так что если количество детей ограничено, то сойдет.

Далее при обновлении связей надо делать:
1. проверять по индексу валидность операции, и если да, то
2. обновлять данные, а далее
3. обновлять этот индекс (в простейшем случае значение одного поля)
Естественно, внутри транзакции.

На НФ вообще не стоит обращать большого внимания, но если Вы все-таки хотите концептуальной чистоты, то проблем нет никаких. Вы имеете право создавать индексы для оптимизации доступа к данным, которые как следствие будут повторять содержимое в том или ином виде (необходимая избыточность). Пример, если хранить строки, то может понадобиться знать количество гласных ну или еще что-то. Это можно хранить в отдельной колонке, но очевидно, что это избыточность. То же самое здесь. Вы просто храните вспомогательный индекс.

Конечно, в хорошей модели данных эта информация (используемая для доступа к целевым данным) не должна храниться вместе с оригинальными данными на том же уровне. Например, встроенные СУБД индексы хранятся отдельно. Но так уже РМ устроена, а РСУБД реализованы, что там все в одну кучу свалено, да и понятия доступа не существует. Да что приходится юзать что есть. Но главное здесь это понимать роль этой вспомогательной колонки: это не (оригинальные) данные - эти ваш индекс, а у него своя собственная логика, отличная от логики основных данных. Для связи же данных по-прежнему используется третья таблица. Такой подход используется очень часто, так что никакого криминала тут нет.