Как правильно организовать разделение физических и юридических лиц?

Question

[yar_s]

Здравствуйте, мне в курсовой нужно разработать базу данных для аукционной фирмы.
Участники аукциона могут быть как физическими, так и юридическими лицами. Я создал соответствующие таблицы, но теперь не знаю как организовать хранение информации о владельце и о покупателе. Думал ввести таблицу участников, где бы вводился их общий индекс, логическая переменная (ФЛ / ЮЛ) и внешние ключи со ссылками на ФЛ и ЮЛ. Но это как-то косячно выглядит)
Я думаю, это типичная ситуация и есть нормальное стандартное решение. Подскажите, пожалуйста.

Answer 1

[Evgeniy Zavyalov]

Данных мало, но сделал бы так:

Название	Описание
ID	автоинкрементное поле
TYPE	0-физик; 1-юрик; 2-ИП
SHARE	0-Участник; 1-Нет
РЕКВИЗИТЫ	Остальные общие реквизиты

и пару таблиц для реквизитов (если необходимо)
- таблица для физ
- таблица для юр/ип

Будет у вас ID клиента и используете его в таблицах сделки, товары ...

ИНН не указывал бы в качестве PK, т.к.
- ошибок ввода ИНН никто не отменял
- ИНН не всегда будешь знать ( 100% )

Answer 2

[АртемЪ]

Таблица физических лиц со своими реквизитами.
Таблица юридических лиц со своими реквизитами.
Участник аукциона - элемент одной из этих таблиц.

Еще вариант -
Таблица контрагентов содержащая реквизиты как ЮЛ, так и ФЛ.
Участник аукциона элемент этой таблицы, в зависимости от типа заполняются нужные реквизиты.

Comments

[yar_s]

Про первый вариант я уже написал, но не знаю, вводить ли общий индекс (а иначе - как?). А во втором случае получится много NULL'ов и так, вроде, нельзя

[АртемЪ]

yar_s: Не совсем понимаю что вы подразумеваете под общим индексом.
Насчет второго случая - почему много NULL'ов и почему так нельзя?

[yar_s]

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

[АртемЪ]

yar_s: Ну какой то ключ должен быть первичным, правильно? И в чем конкретно проблема? Я не вижу сложности.

По поводу второго случая -да некоторые поля будут не совпадать. И тут возникает два вопроса -
Чем конкретно вам не нравиться NULL, какие проблемы это вызовет?
Почему несовпадающие поля должны содержать именно NULL? Ну не нравиться вам NULL, так заполните реквизиты ФИО юрлица, пробелами или прочерками.

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

[yar_s]

Артем: спасибо, наверное, вы правы: всё мой перфекционизм)

[АртемЪ]

Поймите одну простую вещь - все что я советую основано на представленных вами данных.
А данных вы представили крайне мало. Т.е я вам описываю "сферического коня в вакууме".

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

[yar_s]

Артем: мне нужно хранить еще информацию о сделках и товарах. И я вот думал, как связать эти данные с данными об участниках, которые могут быть как физ., так юр. лицами. Наверное, следовало сказать это раньше

Answer 3

[Rsa97]

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

Comments

[yar_s]

То есть, можно и не вводить искусственные ID'шники?

[Rsa97]

yar_s: Мало того, если есть нормальные естественные id, то искусственные просто не нужны. ИНН записывается цифрами, имеет максимальную длину 12 знаков, то есть его можно вписать в тип BIGINT, для ключа вполне подходит. Единственная проблема, если надо различать физлиц и ИП - у них один и тот же ИНН.

[yar_s]

Rsa97: а как быть, если мне нужно ссылаться на участников как на владельцев и покупателей? Мне же всё равно придётся как-то унифицировать физ. и юр. лиц