Зравствуйте.
Есть такая проблемка....
Необходимо разработать базу в которой будет вестись учет заключенных договоров с учащимися на обучение. Соответвенно в БД должны храниться сведения о договоре, заказчике, и учащемся. 


tbl_MainKontrakt - таблица договоров
-------------------------------------------------
ID - номер договора
Date - дата
IDstu - учащийся
IDzak - заказчик
....  и  т.д.

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

Почему? Просто назначение полей будет различным, возможно какие-то будут незадействованы...

ну так в том то и дело что не хотелось бы оставлять пустые (незадействованные) поля... дело не производительности связанных с  обработкой Null просто мне кажается что это не совсем правильно...
у меня была идея в следующем:

Создать ещё 2 дополнительных таблицы: 

Таблица параметры:
--------------------------
ID_param - Код параметра
Param - Название параметра (Список всех возможных данных о заказчике относящихся как к организации так и частным лицам  - ФИО, Название организации, Адрес, Телефон и т.д)

таблица Заказчики:
----------------------------
ID-идентификатор заказчика
Type - тип заказчика (1-Частное лицо, 2- Организация)
ID_Param - параметр поля (Фамилия, Название организации, Адрес, и т.д.)
Value - значение поля

Этот вариант практически полностью исключает значения Null, но вместе с этим усложняет запрос на выборку данных о заказчике, но этот вариант не понравился мне по другой причине;
т.к. в поле Value будут вноситься различные типы данных числа, текст... то есть задать маску ввода или какое то ограничение на вводимые данные не получится...  Можно конечно сделать проверку вводимых данных в зависимости от выбранного параметра на клиенстском приложении, но опять же у меня сомнения насчет правильности и окончательности этого решения...

Вот именно поэтому я и хотел бы обратиться к более опытным разработчикам, ведь наверняка кто-то сталкивался с аналогичной проблемой, хотелось бы узнать какие варианты решения существуют?

как вариант, можно выделить общее в отдельную таблицу и с ней связывать а для тех параметров которые разные сделать еще 2 таблицы

и в зависимости от типа заказчика делать join или с одной или с другой.
извращаться можно по разному.

Ну да вариант.... , но и у него есть минус
Связывание таблицы Заказчики с 2-мя таблицами в которых будут храниться остальные параметры необходимо делать отношением "один-к-одному" чтобы исключить возможность того что у одного и того же заказчика может быть несколько записей этих параметров в таблице.
Тогда чтобы для обеспечения ссылочной целостности между таблицей заказчики и параметры данных необходимо чтобы запись об этом Заказчике присутствовала в 2-х таблицах этих различных параметров (частных лиц и организаций), опять же получается что этот вариант не подходит
:-(

и всё-таки мнекажется, что как то это можно организовать без извращений..... но пока не могу врубиться каким образом

У тебя есть одна сущность - Заказчик. То, что их несколько (2) принципиально различных типов, ничего не меняет. Ты хочешь идти по пути разделения одной сущности на 2 несвязанных таблицы по вторичному признаку? флаг в руки.

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

Fleks, если уж хочится разделить сущности, что с точки зрения проектирования БД правельно, то делай так, этот способ легко позволяет обьединить сущности в одну:


физ лица:
id_физ_лица 
name 
...
...
...

юр лица:
id_юр_лица_и_ссылка_на_физ_лицо
name
...
...
...
-------------------------------
смысл этого поля "id_юр_лица_и_ссылка_на_физ_лицо" заключается в том, что оно одновременно является первичным ключом для юр лица и вторичным для физ лица, что гарантирует связь один к одному.

шаг второй:
во многих СУБД(какую ты используешь?) есть понятие INSTEAD OF TRIGGER(в оракле называется именно так), это тригер на представление, он срабатывает на DML(insert, update, delete) - операторы к представлению. Таким образом в приложениях можно спокойно редактировать представление, а тригер будет отлавливать это и выполнять нужную тебе процедуру.
Таким образом мы имеем грамотное разделение сущностей на уровне БД, но и без обломов работаем с ними как с одной таблицей на стороне клиента.

Добавлено через 11 минут и 13 секунд


Akina, о какой статистике идет речь?

Это сообщение отредактировал(а) DimW - 7.9.2007, 08:22

Да любой, которая задействует оба типа заказчиков. У меня жена занимается на работе в т.ч. именно этой фигней - учетом договоров коммерческого обучения в институте,- так что предмет мне знаком не по наслышке... ты не представляешь, насколько буйная у ректората и учебной части фантазия... и пока я не переделал полностью ту ублюдочную БД, которая у них была состряпана институтским ВЦ (раздельные таблицы в Экселе, привязка в Аксесс, совмещение хрен знает как и протчая) - были сплошные грабли.

2 Akina, ясно.
я мочему то решил что ты имеешь ввиду админскую статистику по БД.
даже если потребуют статистику о которой ты говоришь то при той связке таблиц что я предложил проблем быть не должно, по сути связь О:О дает возмодность расценивать несколько сущностей как одну, и все что можно дастать при помощи SQL из одной таблицы, то без проблем можно извлечь и нескольких.

Добавлено @ 12:54
осталось выяснить у автора какой сервер БД он использует, и есть ли внем возможность использовать тригера на вьюхи. если конечно его заинтересовала такая возможность.

Это сообщение отредактировал(а) DimW - 7.9.2007, 12:55

DimW - спасибо за совет! Попытаюсь им воспользоваться... 
БД делаю для SQL-server но пока маловато опыта, учусь так сказать на практике. с тригерами мало знаком т.к. до этого увлекался только Access-ом но теперь хочется чего то более серьезного  
Извини, но я не совсем понял смысл поля "id_юр_лица_и_ссылка_на_физ_лицо", каким образом оно одновременно является первичным ключом для юр лица и вторичным для физ лица?
Если я правильно тебя понял, то ситуация должна выглядеть так:

при добавлении нового Юр.лица вносим данные в таблицу Юридических лиц, но учитывая то что у нас есть связь с таблицей Физ.лиц "один-к -одному" для обеспечения ссылочной целостности данных мы должны должны внести связанную запись и в таблицу Физ.лиц. но туда мы можем внести только IDзаказчика (других данный у нас попросту нет), т.е. все остальные поля в этой записи оставляем пустыми, т.е. должны быть разрешены Null во всех полях? Так? И аналогичная ситуация при внесении Физ.лица! так же будет создаваться пустая запись в таблице Юр.лиц и во всех полях должны быть разрешены значения Null 


  или я неправильно тебя понял?

Это сообщение отредактировал(а) Fleks - 9.9.2007, 23:21

именно так.


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


Fleks, почему такое отвращение к нальным полям или боязнь, не знаю как и назвать....
все равно индыксы строятся по первичным и вторичным ключам, а значит и селект для представления по этим сущностям будет работать именно по ним, в производительности ты нечего не теряешь.
Хотя сам подход использования тригеров на представления это гарантирует  (но не намного)
За производительность нужно бороться там где это действительно необходимо, а задача ведения заказчиков и договоров не тот случай.


на сколько я знаю с тригерами на представление у этого сервера все в порядке.

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

Это сообщение отредактировал(а) DimW - 10.9.2007, 12:38