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


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

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

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

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

2StarWind
>Я так понял ввести табличку одно поле которой ссылается на юзера, второе на группу, а на третье ссылается таблица безопасности? А Join'ы писать не замучиешься в связках? по мойму это получается тормоз да и путаница при занесении данных. Особенно после того как к твоей базе решат написать второго клиента, причем писать будет не разработчик.

Ты не так понял, я наверное плохо сформулировал. Правда gringo с уже ответил, но я все-же попробую еще более формально.

create table commonKey (
id int not null identity primary key,
......
);

create table "user" (
id int not null primary key
references commonKey(id),
.....
);

create table "group" (
id int not null primary key
references commonKey(id),
.....
);

И если нужно чтоб что-то ссылалось на юзера или группу, то ссылайся на commonKey.

>теоретически да, а практически группы древовидные и каждый пользователь может находится в нескольких группах. Равно как и несколько пользователей могут быть в одной группе. Хотел бы я посмотреть на таблицу (одну) в которой это возможно.

Желания исполняются:

create table hGroups (
"group" int not null
references commonKey(id),
"member" int not null
references commonKey(id),
.....
primary key ("group","member")
);

Вместо ссылки на commonKey в этой таблице можно ставить ссылки на любую таблицу из множества {"user","member"} в зависимости от той же разнесчастной бизнес логики.

В одну таблицу вообще все на свете запихнуть можно, достаточно создать поля всех типов, первичный ключ типа identity и ссылку на себя. Тут это уже обсуждалось. А нужно ли?

>как правило у групп и у юзеров свой набор атрибутов, какой-то сопровождающей инфо... так что мы тогда получим что для группы или для юзеров окажется куча ненужных полей

Третий раз медленно. Общие поля кладешь в "commonKey" (если они есть, я там многоточие специально поставил) , уникальные для юзера - в "user", уникальные для группы - в "group". Это то же, что gringo предлагал, только вид сбоку. Ссылаешься куда хочешь, ключ у двух таблиц общий. Где тут лишние поля? Это же стандартная техника - приведение к нормальной форме называется, не помню правда к какой.

>Дерево в одной таблице, а остальное по разным и ссылаются на это самое древо, грубо говоря вынесен первичный ключ в отдельную таблицу, или я опять что-то не понял?

Все правильно. Потом можно дерево, можно много ко многим, это уже не важно. Основная идея была - построить общий первичный ключ для нескольких таблиц.