>Нужно
есть древовидный список групп людей и есть список людей. Они лежат в разных таблицах. Между ними отношение многие ко многим, а по сему объеденены они через третью таблицу. Все красиво, все связи прокладываются.
А теперь встает проблема общаться что с группой людей что с конкретным человеком как с одной сущностью. Вот тут и появляется эта ерунда.
Например, есть таблица безопасности в которой можно прописать разрешения на что либо как на группу так и на конкретного человека. Но ссылка на две таблицы не лезет. Вот и приходится баловаться с кодом на триггере или забивать на это на свой страх и риск...


Не нужно. Ничего страшного не появляется. Достаточно, например, завести таблицу GroupUser, кторая будет типа первичным ключем для юзеров и групп (отношение 1:0) и ссылаться уже на нее. Туда же можно общие поля сложить, еще и место сэкономишь.

Насчет выноса логики в сервер приложений или клиент.
За:
-возможность распараллелить обработку запросов, в том числе работать с несколькими серверами. Тут есть много ньюансов, может и медленнее получиться.
-возможность относительно легко перейти на другой SQL сервер (умозрительная по-моему, хотя я слышал о переносе сложной системы вроде бы с оракла на мсскл за пару дней, но что-то не сильно верится). Это только при условии, что выносится вся логика, а в БД остаются только таблицы, да и то не сильно навороченные.
-куча недорогих темных студентов, типа знающих C++ (ASP, VB, .NET..., нужное подчеркнуть);
-меньше работы датабазному программеру и меньше ответственности; (только при условии, что зряплата не страдает);

Против:
-на sql-е многие вещи легче пишутся, например те же пользователи-группы с правами доступа;
-возможность относительно легко перейти на другой клиент (умозрительная, я о таком даже не слышал), добавить доступ через веб;
-если систему строить в лоб, без плясок с бубнами, то наверное производительность системы получится выше.

Я не знаю как лучше, но ИМХО оставить логику в SQL сервере правильнее.