Подскажите, как "методологически правильно" решить проблему...
Есть следующие сущнности:
филиал
сотрудник
клиент

Каждый клиент закреплен за одним филиалом. Каждый сотрудник работает на одном из филиалов.

Есть принципы доступа:
каждого клиента должен видеть один сотрудников
каждого клиента при необходимости могут видеть несколько сотрудников
за каждым клиентом должен быть закреплен ответственный сотрудник
за работу со всеми клиентами филиала отвечает один из сотрудников (начальник)
Каждый клиент входит в одну из групп по жестко заданному принципу
Клиенты могут временно объединяться в особую группу (пул) по произвольному признаку.

Дальше начинается самое интересное.

Первое, что пришло в голову:
1. По каждому клиенту делаем запись - филиал, сотрудник, группа, пул
2. Создаем таблицу доступа, определяющую доступ, делаем в ней поля: логин сотрудника, филиал, группа, пул.

Дальше строим список клиентов для каждого сотрудника запросом:

Проблема в чем: если запрос писать так, то все сотрудники будут видеть всех клиентов филиала, а если добавить в запрос логин, то нельзя сделать доступ к одному клиенту двум сотрудникам (пул для этого использовать нельзя).

Возможные варианты решения:
1. В таблице доступа делать записи не по филиалам/группам, а по клиентам/группам. Тогда можно для клиента сделать две записи, и его увидят два человека.
Минус - филиалов 15, а клиентов 25000, с вытекающими последствиями.
Плюсы - что-то мне подсказывает, что это более верное решение.
2. Видимо, если не использовать первый способ, придется сильно извратиться. Я даже не придумал пока, как...
3. Здесь могла бы быть ваша реклама   

Это сообщение отредактировал(а) RockClimber - 24.6.2008, 10:56

Вопрос номер один:
Какой принцип отбора для доступа между сущностями Клиент - Сотрудник?

Что за необходимость такая? Когда возникает - насколько часто и т.д.
Если необходимость доступа разных сотрудников к одному клиенту достаточно статична - то , значит создаешь таблицу ссылок:
КлиентОрганизацияДоступ с полями
ИД - первичный ключ
Клиент_ИД - вторичный ключ ссылка на ИД таблицы Клиент
Сотрудник_ИД - вторичный ключ ссылка на ИД Сотрудник

Если существуют условно-постоянные группы на которые делятся клиенты и доступ необходим по этим группам, то соответственно делаешь подобную таблицу по группам.

А это что принципы доступа? 

Проблема не обозначена.
Обозначьте - решим.

Во всем вашем сообщении я так и не увидела описания самой проблемы, только способов решения.

Подсказка: формулировка проблемы должна быть в форме "что нужно сделать". А не как сделать непонятно что (в вашем случае).

Это сообщение отредактировал(а) ida - 23.8.2008, 18:06

Что нужно сделать? Нужно разработать такую схему реляционной БД, в которой:

Это оно? Нет? Тогда не знаю...
На самом деле, я все придумал уже, меня устраивает, работает быстро, просто и прозрачно. Пока не внедрено, но скоро будет.

Я не знаю зачем это и кому оно нужно и для чего, но я это уже написал 
Да, это программистский подход 

Чо там разбираться - кодить надо....

RockClimber, можно вас попросить сделать следующее.
Когда продукт будет внедрен и начнут появляться замечания или вопросы от заказчика, помещать их в эту тему.

Немного потренируемся в обратном проектировании.
Думаю, многим будет полезно.

Это сообщение отредактировал(а) ida - 15.9.2008, 13:30

Я знаю, это бывает, когда два человека говорят на принципиально разных языках. Я даже не могу понять, чего именно вы не понимаете, поэтому и не знаю, как это объяснить. Сейчас, когда я уже все придумал, мне решение кажется настолько простым, что я даже не знаю, зачем было помощи просить... А описывать его тут - мне лень, но если вы попросите - обязательно сделаю.
Претензии от заказчика - ну не знаю, я тут един в двух лицах... Сейчас базой занимается другой человек, и выглядит это ужасно. Если я уговорю начальство, что могу лучше и оно изволит выдать мне высочайшее разрешение - то я базу доделаю и буду сам же и админить понемногу... Но свои претензии к собственному решению, если таковые будут, выложу. И тогда мы

Да, кажется понял, чего не хватало... Данные лежат в реляционной БД и надо именно спроектировать набор таблиц и полей, которые будут содержать записи о правах доступа. Согласно принципам, описанным выше. Вот какая была задача...

Опять не то?

Уровень абстракции повысьте.

Данные в БД, права доступа... доступа к чему? доступа кого? доступа для чего?
Где это будет использоваться?
Кем это будет использоваться?
Зачем это будет использоваться?
И что они получат от того, что эти их права будут лежать вот в таком вот виде вот в этих таблицах? 

Это те вопросы, ответы на которые я пытаюсь от вас получить.

Аааааа...
Тут все интересно, т. к. несмотря на то, что придумал я всё это давно, ничего пока не внедрялось. Начальство, которое является основным заказчиком, пока тоже не оперделилось до конца, что нам надо. Но с моей идеей вроде пока все согласились...