ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Фейковый FK
25 сообщений из 48, страница 1 из 2
  1  все
Фейковый FK
    #39253369
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Мужики, вы стаю собак в проектировании съели. Подскажите, как по феншую.

Есть табля с пациентами и табля с персоналом. Они все где-то проживают и эти данные надо хранить. Чтобы не городить, как минимум, две отдельные таблички, на ум пришла мысль хранить эти данные в одной
 
Код: sql
1.
2.
3.
4.
5.
6.
CREATE TABLE TBL_ADDRESS (
    ID                    INTEGER NOT NULL,
    FK_PATIENTS           INTEGER DEFAULT 0 NOT NULL,
    FK_PERSONAL           INTEGER DEFAULT 0 NOT NULL,
    ...
);


и в упомянутых выше двух мастер-табличках создать "неудаляемые" записи с 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
...
Рейтинг: 0 / 0
09.06.2016, 10:54
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253379
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
Док,
Про феншуй не знаю
но вот зачем :
" DEFAULT 0 NOT NULL"
и
" мастер-табличках создать "неудаляемые" записи с ID=0"

совсем не понял
...
Рейтинг: 0 / 0
09.06.2016, 11:04
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253383
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Минимальная контактная информация и должна быть общей: сегодня персонал, а завтра - уже пациент. Ну или наоборот.
А вот уже различающуюся информацию - разделять: для пациента неинтересна специализация, а персоналу не требуется диагноз.
...
Рейтинг: 0 / 0
09.06.2016, 11:09
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253387
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Док, по фэншую ты можешь хранить информацию о физических лицах в одной табличке, а в другой табличке по 1:1 с предыдущей, хранить определение "типа" физ.лица - "Персонал"/"Пациент". Тут, конечно, не мешало бы и третью табличку прибабахать - справочник типов физ.лиц, чтобы была фэншуйная нормализация и отсутствие избыточности.
...
Рейтинг: 0 / 0
09.06.2016, 11:11
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253388
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
m7m,

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

Если не нравиться DEFAULT, можно в триггер на вставку завернуть
...
Рейтинг: 0 / 0
09.06.2016, 11:13
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253390
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
Докm7m,

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

Если не нравиться DEFAULT, можно в триггер на вставку завернуть
а чем null не угодил??
...
Рейтинг: 0 / 0
09.06.2016, 11:15
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253393
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
rdb_dev,

блин, вроде очевидные вещи, но под этим углом я на архитектуру еще не смотрел. Спасибо, что поднял мне веки открыл глаза
...
Рейтинг: 0 / 0
09.06.2016, 11:16
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253394
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Док, ты всё перевернул с ног на голову.
ты перепутал объекты с атрибутами этих объектов.
с точностью до наоборот.

зы: не проктолог? (шутко!)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.06.2016, 11:16
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253398
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Докrdb_dev, блин, вроде очевидные вещи, но под этим углом я на архитектуру еще не смотрел. Спасибо, что поднял мне веки открыл глаза
А если уж совсем фэншуйно, то каждое физ.лицо либо где-то работает (id юр.лица из справочника юр.лиц), либо нет (null) и если id юр.лица совпадает с id вашего мед.учреждения, то персонал, иначе - пациент.
...
Рейтинг: 0 / 0
09.06.2016, 11:25
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253400
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Мимопроходящий,

мне стыдно, как не было давно!

Пошел стреляться править таблички
...
Рейтинг: 0 / 0
09.06.2016, 11:25
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253406
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
rdb_devесли id юр.лица совпадает с id вашего мед.учреждения, то персонал, иначе - пациент.Типа, доктору больничный никогда не требуется?
...
Рейтинг: 0 / 0
09.06.2016, 11:29
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253411
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Basil A. Sidorov, дело не в больничном, а в том, что персонал облизывают лучше. Так-то любое физ.лицо, будь то "персонал" или "пациент" (не резидент мед.учреждения), обратившееся в мед.учреждение (попавшее в таблицу физ.лиц) уж безоговорочно является пациентом, которому время от времени нужен больничный.
...
Рейтинг: 0 / 0
09.06.2016, 11:34
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253412
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Док,

бр... Я бы сделал табличку PEOPLE и в ней бы хранил и персонал и пациентов. Только добавил бы в неё поле PEOPLE_KIND для определения что это за чел сотрудник или пациент. А связи сотрудник-пациент в этой табле по идее быть не должно. Один и тот же человек может быть пациентом у нескольких врачей, и наоборот у одного врача может быть много пациентов.
...
Рейтинг: 0 / 0
09.06.2016, 11:35
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253420
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Симонов Денисбр... Я бы сделал табличку PEOPLE и в ней бы хранил и персонал и пациентов. Только добавил бы в неё поле PEOPLE_KIND для определения что это за чел сотрудник или пациентА я бы не добавлял: есть первичный ключ, вот его и задействовать в отдельных таблицах для персонала и для пациентов.

P.S. Через пару-тройку лет окажется, что человек не просто может менять состояние - он может лечиться, не переставая быть сотрудником.
...
Рейтинг: 0 / 0
09.06.2016, 11:43
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253424
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Basil A. Sidorov,

пожалуй ты прав
...
Рейтинг: 0 / 0
09.06.2016, 11:47
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253436
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Симонов Денис,

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

Но это
Basil A. Sidorovчеловек не просто может менять состояние - он может лечиться, не переставая быть сотрудником
пока сбило меня с толку, щас буду думать, стоит ли так заморачиваться в контексте задачи.
...
Рейтинг: 0 / 0
09.06.2016, 11:55
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253446
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ДокЕсть табля с пациентами и табля с персоналом. Они все где-то проживают и эти данные надо
хранить. Чтобы не городить, как минимум, две отдельные таблички, на ум пришла мысль
хранить эти данные в одной

А какой смысл вообще выносить место проживания в отдельную табличку? Добавить в основные
таблицы по полю "дополнительная информация, включая место проживания в свободной форме"
типа CLOB мешает что-то?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.06.2016, 12:05
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253454
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
ДокBasil A. Sidorovчеловек не просто может менять состояние - он может лечиться, не переставая быть сотрудником
пока сбило меня с толку, щас буду думать, стоит ли так заморачиваться в контексте задачи.
смотря в чем состоит задача...

19274926
19274858
...
Рейтинг: 0 / 0
09.06.2016, 12:12
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253455
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Dimitry Sibiryakov, как бы да, но, ИМХО, KLADR не помешает.
...
Рейтинг: 0 / 0
09.06.2016, 12:13
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253462
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
rdb_devИМХО, KLADR не помешает.
Ну, если Доку понадобится статистика типа "количество пациента по районам", тогда да, а
иначе это только усложнение ввода.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.06.2016, 12:16
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253471
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Dimitry Sibiryakovмешает что-то?
В произвольной форме недостаточно будет, имхо. В более-менее современных МИС сейчас требуется отдельно адрес проживания и адрес прописки (регистрации).

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

rdb_devсмотря в чем состоит задача...
клиент для мелко-средних контор и "врачей-фрилансеров" Отсюда и контекст. Универсального софта нет.
...
Рейтинг: 0 / 0
09.06.2016, 12:23
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253473
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ДокВ произвольной форме недостаточно будет, имхо. В более-менее современных МИС сейчас
требуется отдельно адрес проживания и адрес прописки (регистрации).

Ну так это не исключает произвольную форму:
Адрес проживания: Москва, Кремль
Адрес прописки: Мухосранск, свалка
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.06.2016, 12:27
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253563
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Dimitry Sibiryakovэто не исключает произвольную форму
хочу оставить потенциальную возможность статобработки
"Никогда не знаешь, что придет голову этим пчелам..." (с)
...
Рейтинг: 0 / 0
09.06.2016, 13:21
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253635
HS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
HS
Гость
Просятся три таблицы: Person(люди), Employee(персонал), Patient(пациенты). Sorry - все, что сверху не читал.
...
Рейтинг: 0 / 0
09.06.2016, 14:00
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253722
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
HSПросятся три таблицы: Person(люди)
какие сведения хранятся в первой таблице?
...
Рейтинг: 0 / 0
09.06.2016, 15:21
| Ответить | Цитировать | Написать  
25 сообщений из 48, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Фейковый FK
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39253446&tid=1562137]:
 0ms
get settings:
 10ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 43ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 52ms
get tp. blocked users:
 1ms
others: 12ms
total:  144ms
созд. / загр.: 144ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]