для тех, кто не может скачать IBAnalyst, и не может нажать F1, и не может ткнуть... и т.п. Цитирую:

7. Почему индексы названы "плохими"?
Индексы, имеющие критическую селективность (ниже 0.01) IBAnalyst называет "плохими" по нескольким причинам:

Селективность (избирательность) такого индекса ниже той, которая используется оптимизатором (константа 0.01). Теоретически оптимизатор не должен использовать такой индекс, тем не менее использует, если ничего другого нет.
- Такой индекс приводит к очень медленной сборке мусора.
Данная проблема решена только в InterBase 7.1/7.5, и будет решена в Firebird 2.0.

- Такие индексы сильно замедляют процесс restore, и вообще сами по себе создаются долго (create/alter index active), по причине очень больших цепочек номеров записей для одного ключа индекса.

- Если этот индекс используется в where для проверки на неизвестное значение (по которому много дубликатов ключа), то есть шанс что его использование приведет к сильному потреблению памяти на хранение большого количества ссылок на записи

- Если такой индекс используется в order by, и дубликатов меньших значений больше (т.е. тех, которые располагаются в начале индекса), то будет много чтений страниц с диска, что ухудшит скорость выборки.

IBAnalyst не может не сигнализировать о наличии таких индексов.
Худшим случаем "плохого" индекса является индекс со большим количеством ключей и значением 1 в Uniques, то есть с всего одним единственным значением ключа (см. "Бесполезные индексы" на странице Общая информация IBAnalyst).

8. Что делать, если "плохой" индекс построен по FK?
Действительно, из предыдущего пункта ясно, что от "плохих" индексов стоит избавиться. Однако, если такой индекс построен по Foreign Key, то удалить его можно только вместе с Foreign Key. А это приведет к отсутствию контроля целостности между двумя таблицами.

Вы можете заменить FK контролем целостности в триггерах, но с определенными ограничениями. FK контролирует связи между таблицами посредством индекса, а индексы "видят" все значения ключей, независимо от состояния транзакций, их модифицирующих. Как результат, очень легко отслеживается ситуация с изменением столбца PK (первичного ключа) в справочной таблице, удалением записи из справочника и т.п. Триггерами отследить такие ситуации нельзя, т.к. они "видят" только те записи, которые разрешено видеть транзакции, их вызвавшей.

Поэтому, при замене FK триггерным контролем целостности должны быть соблюдены условия:

- записи из справочника никогда не удаляются, или удаляются в монопольном режиме (см. транзакции reserving в статье по транзакциям)
- столбец первичного ключа справочника никогда не модифицируется (можно создать такой запрет триггером before update).

При соблюдении этих условий FK можно удалить, и разумеется, строить индекс по этому же столбцу не нужно.

авторберем id группы и делаем вставку. Каким образом меня спасает в данной ситуации триггер? Удалять нельзя, обновлять тоже?
вопрос почти риторический, если я его правильно понял. Клиент видит только то, что зашито в БД, и справочная таблица спокойно может быть заменена на набор констант в приложении.
Чего я не понял, так это где именно должен "спасти" триггер. И вообще зачем он нужен в данной ситуации, для пользователя. Для девелопера он нужен, чтобы тот не сломал целостность в БД через IBExpert.