...Чем больше нахожусь в форуме, тем меньше курю - невозможно оторваться:-))).

Вопросом мучаюсь давно, но духу не хватало спросить. Я не из крутых программеров, потому сомнения меня гложут (или глодут...) по поводу созданной мною же структурки базы данных. База работает, все ОК, но кажется мне не так оптимально все выстроенно там, как могло быть. А именно смущает меня схема данных, т.е. завязка таблиц друг с другом. Пока проектировал - трижды делал совершенно разные схемы, а когда закончил и поставил, то осталось ощущение недоделанности и успокоится немогу. Кому интересно, изложу поподробней.

...ну тогда слушай... сам нарвался...:-)))

Было это так. Четыре основных таблицы: Клиенты, Менеджеры, Объекты и ЗадачиПоОбъектам. У каждого менеджера есть несколько клиентов, соотв-но один-ко-многим. У каждого клиента - свои объекты, соотв-но опять один-ко-многим. Ну и у каждого объекта свои задачи, то есть в результате задачи, которые должен выполнить менеджер, у которого в списках имеется клиент, работающий с этим объектом. Это в простом варианте и без доп. условий. Здесь, как видите, все четко, без проблем (для многих из вас как 2х2). Когда же появились доп.условия, пришлось все перелопатить наново.
Первое. Оказалось, что возможны три типа объектов:
1. Объект, у которого сразу определен клиент.
2. Объект, у которого клиент определяется только после
так называемого тендера, в котором учавствуют несколько клиентов.
3. Свободный объект (свободный от клиента, пока; но менеджер уже
работает с ним, то бишь задачи уже ставятся и выполняются).

Две последних категории объектов в будущем обязательно переходят в первую, то есть конечное состояние объекта - п.1.
В результате всего этого, пришлось создать таблицу (назовем её ГрупТаб) с составным ключом, типа Кл_id + Об_id и булевым полем "В работе", что помогло решить вопрос с тендерами, но тогда как отслеживать свободные объекты? Как прописать отдельно фамилию менеджера (мен) к свободному объекту, а потом, на основании этой информации предложить меновский список клиентов и внести новую запись в объединенную таблицу? пришлось добавить в ГрупТаб ключ Мен_id и вся схема выглядела так: в центре ГрупТаб, а к ней по ключам прилинкованы три таблицы - Мен, Клиенты и Объекты. А для таблицы Задачи связь по полю счетчика записей в ГрупТаб(поскольку теперь имелся смысл постановки задач для каждой строки таблицы ГрупТаб, то бишь и для менеджеров, клиенты которых учавствовали или учавствуют в тендере). В результате получилось, что в одной записи этой таблицы (ГрупТаб) может отсутствовать наименование Клиента, в другой - ФИО Мена, и т.д. Не смог ничего больше придумать, оставил как есть. Слава Богу, вытащить информацию о клиентах и задачах Мена смог на форму и в отчет, но блин, нескладно как-то все это.
Все ли написал? Если хватит терпения разбираться, буду только рад. А если нет, да и Бог с ним.

Спасибо за отклик. Только вот заковыка в том, что потом, каждому свободному объекту все равно должен приписан быть клиент, то бишь связка мен-объект временная, пока клиент не определен. Но в то же время вся инфа должна оставаться в базе (т.е. инфа о том, кто участвовал в тендере, какой объект был свободен и т.д.). По вышеуказанной схеме так не получается...

...у меня получился вот такой вид таблицы ГрупТаб:

...где:

об3, бо5 - свободные объекты;
об1, об2 - обычные объекты;
об4 - проходящие по тендеру...

Ну так как по вашему, это нормально? Аксакалы?

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

Попробую подробней о самих таблицах:

1таб. "Клиенты": cl_id (ключевое), men_id(внешний ключ для определения - какой клиент к какому мену относится).
2таб. "Менеджеры": men_id(ключевое), lname, fname,.......
3таб. "Объекты": obj_id(ключевое), name_obj ,....
4таб. "Задачи": task_id(ключевое), task, result, .......
5таб. "ГрупТаб": groop_id(ключевое), cl_id, men_id, obj_id, task_id - эти четыре связаны с соответств. таблицами.

Сама реализация этого вопроса возможна в другом исполнении или нет? Думается мне, что оптимальностью в моем варианте и не пахнет...

>И вообще, попробуйте лучше покороче саму проблему описать без всяких таблиц и Ваших решений

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

да, но при этом если ты поставишь в эту таблицу людя типа менеджер, то никогда больше не узнаешь, с каким клиентом работает этот объект. Дело в том, что менеджер как посредник между объектом и клиентом. И если клиента пока нет, то он все равно в конце концов будет, а у тебя так не получается...

Хорошо, завтра я попробую сконцентрировать свою волю и все что нужно для постановки четкой задачи... До завтра.

А как ты узнаешь потом, какому своему клиенту Сидоров отдал этот объект? И какие у этого Сидорова вообще клиенты?

...у каждого мена куча клиентов, которым они рассовывают свои объекты...

А вот это ты зря. Я весьма рад, что слышу здесь постоянно Сенина Виктора, Лоха Позорного, Владимир Саныча, Хама Трамвайного и т.д.. Многим из них здесь обязан.