Мужики, вы стаю собак в проектировании съели. Подскажите, как по феншую.

Есть табля с пациентами и табля с персоналом. Они все где-то проживают и эти данные надо хранить. Чтобы не городить, как минимум, две отдельные таблички, на ум пришла мысль хранить эти данные в одной

и в упомянутых выше двух мастер-табличках создать "неудаляемые" записи с ID=0, а при вставке в TBL_ADDRESS в FK вставлять реальный ID из той таблички, для которой запись создана.

Так нормальные люди делают или есть какой-то другое правильное решение с учетом последующего удобства выборки и проч.?

=================
Док.

Win7 Ultim x64, Deb 7.6 i386 (Deb 8.3 i386): FB 3.0.0.32483, диалект 3, SS(win)/CS(Deb), Lazarus 1.7; FPC 3.1.1, IBX by -Rik-; IBE 2016.4.29.1

m7m,

еще раз: если указан адрес проживания пациента, то в FK_PATIENTS будет не 0 , а в FK_PERSONAL будет 0 . Для адреса работника ситуация будет с точностью до наоборот.

Если не нравиться DEFAULT, можно в триггер на вставку завернуть

rdb_dev,

блин, вроде очевидные вещи, но под этим углом я на архитектуру еще не смотрел. Спасибо, что поднял мне веки открыл глаза

Мимопроходящий,

мне стыдно, как не было давно!
Пошел стреляться править таблички

Симонов Денис,

тут уже предлагали. Я даже в инет сунулся, рассуждая, как ты

Но это
Basil A. Sidorovчеловек не просто может менять состояние - он может лечиться, не переставая быть сотрудником
пока сбило меня с толку, щас буду думать, стоит ли так заморачиваться в контексте задачи.

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

rdb_devKLADR не помешает
нафиг, я решил, что в базу его пихать не буду, если только рядом положить и отдельным коннектом оттудова данные доставать и писать в свою (скорее для удобства юзверей)

rdb_devсмотря в чем состоит задача...
клиент для мелко-средних контор и "врачей-фрилансеров" Отсюда и контекст. Универсального софта нет.

Dimitry Sibiryakovэто не исключает произвольную форму
хочу оставить потенциальную возможность статобработки
"Никогда не знаешь, что придет голову этим пчелам..." (с)

HSПросятся три таблицы: Person(люди)
какие сведения хранятся в первой таблице?

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

zeon11Пациентов и персонал нужно хранить в разных таблицах
Дык это и было описано в стартовом посте :)

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

Когда я положил докторов и пациентов в одну корзинку табличку, угадайте, какой вопрос мне пришел в голову?
Го-стхиТС-у так монструоно не нужно)
абсолютно верно, я уже тут писАл об этом

Мда, нет в мире совершенства ...

zeon11,
это очень просто объясняется: я принимаю, как минимум, в двух клиниках (на три уже не хватает ни сил, ни желания). Базу ношу с собой на флешке. В конце рабочей смены вывожу отчет на печать с сформироваными итогами. Вот тебе и id клиники.

Если базу пользует одна контора, то понятна необходимость id доктора.

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

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

Я делаю новую базу на основе старой, которая была спроектирована более 7 лет назад. Очевидные огрехи исправляю. Увы, новые тоже появляются. Некоторая денормализация - вынужденная мера за универсальность, главное - чтобы во всем был разумный предел

zeon11,

там пока в основном только амбулаторный прием и есть. По скринам можно примерное представление составить (прямых ссылок постить не буду, можно найти из профиля)