Доброго времени суток!
В базе ожидается множество видов контрагентов: поставщики, покупатели, перевозчики, охранные предприятия, ремонтники и т.д.
Какое их сходство:
1)Все они могут подразделяться на два типа (к примеру юр. лица и частники).
2)Структура контактной информации у всех контрагентов одинаковая, только есть небольшое отличие по типам (Если юр лица

, то Наименование компании, ИНН, КПП, рс и т.д.; если физ лица - ФИО, год рождения, паспортные данные)

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

собственные отчеты.

Какое я решение вижу:
Создать таблицу аля _Types - в ней создать следующие поля:
>id_type
name_type
prefix_type
description

Получим таблицу типов. В нее можем занести все виды контрагентов с уникальными префиксами типа (client_, security_ и т.д.).
Эти префиксы потом будут подставляться к наименованию таблицы, которая относится только к этому контрагенту (например:

таблица заказов client_ order)


А далее создаем 3 таблицы:
1) Persons
>id_person
status (тип юр лицо либо физ лицо; по поводу типа данного поля пока затрудняюсь (либо INT переключатель 1|0; либо это тоже

будет ключ из таблицы status_person, в которой будет всего два поля (id_status, status) и две записи ))
2) Jur_person (для юр лиц)
>id
id_person (ключ из таблицы Person)
id_type (ключ из таблицы _Types)
name
contact
INN
KPP
.......
3) Phys_person (для физ лиц)
>id
id_person (ключ из таблицы Person)
id_type (ключ из таблицы _Types)
name
surname
...........


Пожалуйста, покритикуйте!

Edkonst2008 , авторПо пункту 1 - а есть понятие, куда отнесете ПБОЮЛ ?
В задании про это ничего не говорится, но никто не даст гарантии, что такого рода предприниматели не появятся. Поэтому я склоняюсь больше к варианту с отдельной таблицей юридических статусов.

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

По поводу атрибутов. Скорей всего будет оптимальней создать одну таблицу аттрибутов и одну таблицу на значения этих аттрибутов.

В итоге я пока альтернативу вижу следующую:
1) Person_status (юр статус различных лиц)
>id_status
name_status

2) Person_list (список всех контрагентов)
>id_person
id_status (внешний ключ от таблицы person_status)

3) Person_attribute_list (список аттрибутов, которые будут встречаться)
>id_person_attribute
name
type (тип данных (int, bool, string))

4)Person_attribute_value (значение аттрибутов)
>id
id_person
id_person_attribute
value

Пока слабым местом здесь вижу тип данных и разделение на значение аттрибутов. Пихать в текстовое поле абсолютно все: числа и болевые значения не считаю хорошо. Тут вариант решения следующий, либо в 4-ой таблице добавить поля value_int, value_bool, value_decimal,
либо как здесь на разные таблицы. Мне кажется, что приемлем больше первый вариант.

Что скажете?

авторуродливый синтаксис
А не подскажете где можно почитать про стандарты наименования полей и таблиц в БД?

Такая таблица хорошо известна и называется ОКОПФ
Не изобретайте велосипед, ознакомьтесь с перечнем общероссийских классификаторов.
Спасибо, приму к сведению.


По поводу наследования - оно бы все хорошо, если бы не MySql. В Posgresql или Oracle - это решается на раз.

Насчет загруженности БД при применении EAV согласен - момент узкий.

А вообще, обратил внимание на 1C. Там очень грамотно на мой взгляд сделано.
Единый справочник контрагентов (в нем как физ так и юр лица - никаких доплнительных делений на ПБОЮЛ ЗАО нет - и отличий там немного КПП заменяется на ФИО) и все они могут быть разделены на разные группы, причем может быть группа в группе.
Ткнул этим примером составителем задания - они согласились то, что действительно полей "несхожих" не так уж и много.

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

Вот как можно сделать после "послабления" тз.

PersonGroup (Таблица групп)
>IdGroup
Name

PersonGroupContent (Содержания групп)
>Id
IdGroup
IdPerson

PersonStatus (Таблица статусов Юр. Физ лица)
>IdStatus
Name



PersonListGeneral (Общая таблица контрагентов)
>IdPerson
IdStatus
Name
INN
....
....
...


PersonListJur (таблица юр лиц дополнение)
>Id
IdPerson
KPP
.....


PersonListPhys (таблица физ лиц дополнение)
>Id
IdPerson
FIO
.....


Т.е. что получается на выходе, т.к. у нас нет отдельных таблиц поставщиков, охраны , то эти значения придется забивать в указанные в выше таблице, в качестве умолчательных групп с запретом на их редактирование и удаление.
Что скажете?