Дано:
Каталог партнеров. Партнеры представляют собой фирмы с 1..Н работниками. В базе должна храниться информация как о фирме, так и о работниках. Фирмы имеют категории, точно так же как и их работники имеют свои отдельные категории. Например: строительная фирма и ее работники: монтажники, маляры и т.д. В роли фирмы может выступать и отдельно взятый человек, например индивидуальный преприниматель.
Мое решение:
Создать таблицу "Партнер", в которой будут храниться оба типа объектов, фирмы их работники будут связаны между собой ключом, индивидуальные предприниматели такого ключа иметь не будут и будут представлять собой фирмы.

Вопрос:
Оптимально ли мое решение, или можно это как-нибудь по-другому реализовать?

Кот Матроскин,

а как же мне потом организовать выборку, если у меня будет несколько таблиц? Т.е. я хочу видеть к примеру последних добавленых н партнеров. Придется ведь обе таблицы опрашивать каждый раз. Или тот же поиск по категориям партнеров. Ведь у индивидуальных предпренимателей тогда не будет связи с категориями фирм, если я их буду хранить в отдельной таблице.

Кот Матроскин,

Хранить один и тот же объект в двух таблицах? Хм, не проще ли тогда делать как я это предложил?

lLocust,

Спасибо, за пространственный ответ. Множества аттрибутов (вы слишком много их додумали за меня) действительно пересекаются. Если я вынесу адрес в отдельную таблицу, то они будут практически идентичны. Не могли бы вы мне пояснить, почему мое решение нерационально? Исходите пожалуйста при этом только из той информации, что я написал.

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

Ну тогда Вы по-подробнее опишите что в итоге нужно? Если Вам нужно хранить ИП как работника - храните. Жалко, что ли? Если у Вас фирма отличается от человека только адресом, то зачем вообще вводить какие-то понятия... Храните все в одной таблице, а адреса в другой...
В уже существующей схеме все реализованно так, как вы и предлагаете, т.е. фирма - работник (1 к Н). Выборка в большинстве случаев происходит по фирме, есть также возможность искать конкретного специалиста по специальности. Для создания есть 2 формы: для фирмы с возможностью выбора специализации фирмы и форма для рабочего с возможностью выбора его собственной специализации. Цель - возможность учитывать ИП. (или, если точнее, людей работающих в одиночку). Т.е. если я просто буду делать из ИП фирму, то нет возможности выбрать специализацию рабочего, если буду делать из него рабочего, то нет связи со специализацией фирмы. Опять же, как я уже сказал, выборка происходит почти везде по фирмам и если я оставлю 2 таблицы, то мне нужно будет как-то комбинировать результаты выборок из 2 таблиц. Сортировка, постраничный вывод, давай до свидания.

Всем большое спасибо за помощь. Думаю, что так и поступлю.

ssas12345Улыбнуло :)
Теоретические рассуждения студентов. Представленная схема полетит к чертям в реальной жизни и при большом охвате.
Например,
ООО "Лютик" в мегаполисе может быть несколько десятков, заполненность атрибутов и их достоверности может не быть по определению, кто когда в какой компании работал - тоже тот еще вопрос отследить
и т.д. и т.п.

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

ssas12345,

авторпоскольку схему своих решений вы не предложили, а предложил только lLocust
то додумывать приходится.
Я описал проблему и описал свое возможное решение. Если бы оно меня полностью устраивало, я бы не спрашивал мнения уважаемого сообщества. Я миллион раз повторил, что не нужно ничего додумывать. Исходя из ответов, я могу заключить, что меня поняли: привели весомые доводы против моего решения и предложили другое.

авторТак, как минимум в схеме должно быть отражено решение по идентификации и унификации фирм. ИНН/КПП не всегда могут быть известны.
В вашем каталоге - да, в моем - нет. Да я даже понятия не имею, что значат эти ваши ИНН, КПП (хотя нет, кпп - это же контрольно- пропускной пункт, да?) - такой я тупой.

авторКак будут учитываться понятия холдинга, групп компаний? (а Заказчик или жизнь - они это запросят рано или поздно)
Как будут учитываться периоды актуальности информации?
Сотрудники имеют характеристику иерархичности, требуют систематизации, т.к. просто список в 3-5 тысяч ФИО - вряд ли удачное решение.
Также, нередко интересна инфа о первых лицах компаний
1. Никак. Заказчик не попросит.
2. Никак. Это не нужно.
3. Нет, не имеют они иерархичности, систематизированы по специальностям.
4. Кому они нужны, эти первые лица? Мне точно нет.

авторКаталог партнеров - слово каталог очень сильное - то не просто накидать пару табличек.
Сильным словом является скорее прилагательное в превосходной степени. В остальном же вы скорее решаете свою задачу: создаете свой каталог и по вашим представлениям.

авторКачество своих баз данных я очень жестко контролировал и контролирую.
Я ни капли не сомневаюсь в вашей компетентности, но вы уже переходите от контроля своих баз к контролю моих.

Всем удачного дня.

ssas12345saturnxxi,

тогда не называйте это каталогом.
Это просто таблица-список каких-то слабоидентифицированных компаний. Этот справочник начнет превращаться в свалку при количестве записей этак > 500
Про незнание ИНН,КПП - тут совсем грустно

будем считать, еще Учитесь

1. Катало́г (от греч. κατάλογος) — в общем случае, некий список информации об объектах, составленный с целью облегчения поиска этих объектов по какому-то признаку. По-моему тут все понятно. Если у вас есть другие определения, милости просим.

2. У вас глобус России на столе стоит? Или иначе: за МКАД-ом жизни нет?

3. Учиться никогда не поздно. Особенно при наличии таких высокомерных менторов.