guest_rusimport,

Охо-хоо...

Попробуй в своей модели отправить "врача-терапевта" на прием к "врачу-стоматологу".
:)

Akina... впрочем, если сказать нечего, а очень хочется, то сойдёт.
Тот факт, что кто-то не понял сказанного,
не означает того, что полезного сказано не было.
:)

guest_rusimport...
ну, модель не моя, а ТС...
У ТС ее нет.
Она за ней пришла.

guest_rusimport .., так дайте ей свой вариант
Не могу.

На основании заданного набора полей,
для меня это невозможно.

А если я начну добавлять свои и удалять лишние,
это не впишется в ТЗ.

Такая вот дилемма.
:)

guest_rusimport ... может я ошибаюсь и задача не учебная...
Не, не ошибаешься.
Задача, конечно, учебная.
И "творчество" в данном контексте не оценят ни студент, ни преподаватель.

Даже если я предложу не разделять описание людей по разным таблицам на белых и черных врачей и пациентов.
:)

Akina... один экземпляр сущности "пациент" и один экземпляр сущности "врач". ...

"Пациентами" и "врачами" не рождаются.
Рождаются "людьми".

ФИО, дата рождения, фотография - атрибуты "человека",
а не "врача", и не "пациента",
и не медсестры, и не охранника, и не ... прочие профессии, должности, воинские и ученые звания ...

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

Сегодня один человек в роли врача, другой его коллега в роли пациента,
завтра аккурат наоборот.

И в вашей модели вы будете описывать одного и того-же человека в двух таблицах,
и в "врач" и в "пациент".

Шыфл... А врачу карточку заводить не нужно?...
Нет.

Болеет не "врач", болеет "человек".
Карточку нужно заводить "человеку".
:)

И, кстати:
AkinaВ данном случае объединение сущностей "врач" и "пациент" в одну сущность "человек" не оправдано...
Я этого и не предлагал.

Akina...А в чём тогда состояло предложение? ...
Predeclared... не разделять описание людей по разным таблицам на белых и черных врачей и пациентов.

Akina... "Копировать сведения из учётной карты врача в его мед. карту" и наоборот.
Это не метод рбд.
Это метод а-ля Excel, Word, Paint.

Akina...Потому как это находится за пределами бизнес-логики.
Абсолютно нет.
Бизнес-логика не запрещает людям,
выступающим, в основном, в роли врача,
иногда выступать в роли "пациента".

Akina..., а из другой таблицы этой же БД - моветон и не метод? ...
Однозначно.
Не должно быть в рбд (даже гипотетической возможности) наличия описания одинаковых атрибутов одной единицы
в двух и более таблицах.

хы. Это базовые вещи, мне даже неловко об этом вслух тут говорить.

Akina... То есть "равенство полов" предлагается реализовать в схеме БД, заведомо при этом получив NULL в нескольких полях подавляющего количества записей? ...
Я этого НЕ предлагал, заметьте.
:)
Akina... Что будете делать, например, с полем "мед. образование", которое обязательно для врача и необязательно для пациента...
Поскольку образований может быть несколько, я опишу табличку "Образования",
которую свяжу с табличкой "Люди".
В этом варианте мне не придется пытаться в одном поле уместить все полученные образования человеком,
коих для человека в роли врача на протяжении его профессиональной деятельности дОлжно быть немало.
+ имею возможность указать где и когда было получено соответствующее образование.

Для людей, выступающих в роли "пациента", наличие записей в таблице "Образование" не обязательно.

Akina... Как будете запрещать врачу принять самого себя...
А что, уникальные индексы уже запретили в Jet?
авторА мужики-то не знают!
:)

Akina... У меня почти в каждой таблице есть одинаковый атрибут - синтетический первичный ключ. И вроде неплохо живу... дата...
Не препятствую.
Я то конкретнее говорил:
PredeclaredНе должно быть в рбд ... наличия описания одинаковых атрибутов одной единицы в двух и более таблицах.

Akina... И на что же, позвольте узнать, будете уникальный индекс накладывать? ...
Тут ваша правда, признаю, лажанулся, не индексом конечно.
Пример разруливания для "учебной" модели:

__Michelle...Это что, запрещено законом?
Не знаю насчет закона,
но в необходимости такого рода ограничений Akina безусловно прав,
если рассматривать не конкретный пример оказания медицинских услуг,
а в более широком спектре.

Akina...В моей схеме врач и пациент - это две разные единицы, даже если физически это один и тот же человек...
Вот аккурат в этом и есть ошибка этой схемы.

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

Вы будете добавлять таблицы соответственно "медсестры", "ассистенты", "консультанты" и прочая и прочая?
А они (консультанты, ассистенты и тд) тоже могут выступать в неосновной роли: пациентов, консультантов, ассистентов.

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

Мешанина, а не бд получается.

К слову:
У вас, наверное, есть возможность посмотреть database model бд форума на винграде?
Поинтересуйтесь, как там описаны мемберы-спрашиватели, мемберы-отвечающие и мемберы-модераторы.

AkinaЕсть две сущности. Человек, предоставляющий услугу (врачи. медсёстры и пр.), и человек, получающий услугу.
И чем это отличается от мембера-отвечающего, предоставляющего услугу в виде ответа,
от мембера-вопрошающего, получающего услугу в виде ответа?
:)
На винграде все мемберы в одной табличке, включая, мемберов с особыми правами (модераторов).
А у вас люди почему-то в двух.
И отличаются они (люди) аналогично мемберам форума: различными правами (и обязанностями) в конкретном взаимодействии.

Вы и контрагентов на продавцов и покупателей по разным таблицам разделяете?