ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Фейковый FK
23 сообщений из 48, страница 2 из 2
  2  все
Фейковый FK
    #39253732
HS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
HS
Гость
Док,
Person - все небходимые вам атрибуты физических лиц.
Employee(Сотрудники) - fk на Person плюс все дополнительные атрибуты медиков.
Patient(Пациенты) - fk на Person плюс все дополнительные атрибуты пациентов.
При этом ваши медики могут быть вашими же пациентами. Employee, Patient - возможно понадобятся дополнительные таблицы.
...
Рейтинг: 0 / 0
09.06.2016, 15:31
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253757
HS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
HS
Гость
Док,

Address (
AddressID
PersonID,
CountryID,
RegionID,
TownID,
Street,
Code
fk (PersonID) Person (PersonID)
)
У человека может быть один или более адресов.
...
Рейтинг: 0 / 0
09.06.2016, 15:52
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253765
HS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
HS
Гость
Док,
Замечу без ложной скромности, что это платиновый, бриллиантовый феншуй )))
...
Рейтинг: 0 / 0
09.06.2016, 15:57
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253840
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
HSЗамечу без ложной скромности
хм. на первый взгляд, больно уж развесистая клюква получается. Беда в том, что я четко не представляю, какие аттрибуты и тех, и других могут потом понадобиться. Отсюда сомнения. В любом случае, спасибо за идеи.
...
Рейтинг: 0 / 0
09.06.2016, 17:43
| Ответить | Цитировать | Написать  
Фейковый FK
    #39253872
Tactical Nuclear Penguin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tactical Nuclear Penguin
Участник
HSДок,

Address (
AddressID
PersonID,
CountryID,
RegionID,
TownID,
Street,
Code
fk (PersonID) Person (PersonID)
)
У человека может быть один или более адресов.

надо еще добавить ID истории болезни. адрес может меняться....
...
Рейтинг: 0 / 0
09.06.2016, 19:09
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254007
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
Tactical Nuclear Penguinнадо еще добавить ID истории болезни.
Не нужно, в болезнях будет fk на носителя. Это и будет историей.
...
Рейтинг: 0 / 0
10.06.2016, 08:56
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254229
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
HS
Address (
AddressID
PersonID,
CountryID,
RegionID,
TownID,
Street,
Code
fk (PersonID) Person (PersonID)
)
У человека может быть один или более адресов.
......
Замечу без ложной скромности, что это платиновый, бриллиантовый феншуй )))

Угу, подойди поближе :-)

У Дока поликлиника или больница. И прежде чем что-то там говорить про фен-шуй, стоило-бы вспомнить, что по адресу как правило живёт несколько человек, и, как правило, они все иногда болеют. Следовательно из твоего фен-шуя надо выкинуть PersonID и привести всё к 4 НФ.
...
Рейтинг: 0 / 0
10.06.2016, 13:35
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254261
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Док,
Пациентов и персонал нужно хранить в разных таблицах, поскольку персоналом управляет сотрудник отдела кадров (ну, или там автоматический обмен с кадровой программой), а пациентами управляют медработники, соответственно к таблицам должны иметь доступ разные роли. Если они все будут в одной таблице, то ты их (пациентов и персонал) по ролям не разделишь и получишь в дальнейшем проблемы. А вот таблицу адресов можно наверное сделать и одну общую.
...
Рейтинг: 0 / 0
10.06.2016, 14:06
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254267
Го-стхи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Го-стхи
Гость
HSAddress (
AddressID
PersonID,
CountryID,
RegionID,
TownID,
Street,
Code
fk (PersonID) Person (PersonID)
)
У человека может быть один или более адресов.

А почему Street без ID? Или номер дома :) Феншуйствовать, так до упора.
И да, PersonID лишний.

*Вопрос в сторону* Нахуа системе знать адреса врачей?
*Вопрос в струю* Как насчет защиты ПДн? Любой врач сможет посмотреть адреса не только своих пациентов, но и других врачей?
...
Рейтинг: 0 / 0
10.06.2016, 14:11
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254271
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Го-стхиА почему Street без ID? Или номер дома :) Феншуйствовать, так до упора.
так вообще - а к чему эта самодеятельность, т.е. почему не КЛАДР или ФИАС?
Го-стхиНахуа системе знать адреса врачей?
это кадры. при приеме на работу конторе надо знать адрес сотрудника.
Го-стхиЛюбой врач сможет посмотреть адреса не только своих пациентов, но и других врачей?
а значит, адрес пациента и адрес врача - это не одно и то же, и они должны храниться отдельно. Пусть и в общем списке адресов, но доступ к кадрам должен быть только у кадровика.
...
Рейтинг: 0 / 0
10.06.2016, 14:17
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254278
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
MaratIskrdb_dev,

даже не вникая в суть, я б тебе руки оторвал
автора в другой табличке по 1:1

один-к-одному = дилетант )))

Да, безаппеляционное заявление :-(
отношения 1:1 в БД - вещь как раз очень профессиональная.

Попробую проиллюстрировать хотя-бы одним примером.

Например, есть таблица, доступ к которой имеют пользователи с разными функциональными обязанностями, пусть, если разговор о медицине, врачи и медсёстры. Причём какую-либо группу полей могут редактировать врачи, а медсёстры эту группу полей только просматривать. Можно конечно, благо FB позволяет, решить проблему назначением прав на каждое поле таблицы, а можно и просто эту группу вытащить в отдельную таблицу в отношении к родительской как 1:1 и уже этой отдельной таблице назначить права.
...
Рейтинг: 0 / 0
10.06.2016, 14:23
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254291
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvпри приеме на работу конторе надо знать адрес сотрудника.
Причём в основном - исключительно для информирования (мало)компетентных органов.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.06.2016, 14:39
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254339
Го-стхи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Го-стхи
Гость
kdvтак вообще - а к чему эта самодеятельность, т.е. почему не КЛАДР или ФИАС?
Во, это вообще убер-феншуй, только, наверно, ТС-у так монструоно не нужно))
kdvэто кадры. при приеме на работу конторе надо знать адрес сотрудника.
Дык тогда получается, что есть два типа владельца адреса, но по сущности это совершенно разные объекты, и хранить их совместно означает протекание абстракции, не говоря уже о всяческих косяках с контролем доступа.
kdvа значит, адрес пациента и адрес врача - это не одно и то же, и они должны храниться отдельно. Пусть и в общем списке адресов, но доступ к кадрам должен быть только у кадровика.
Ага.
В общем, большого смысла объединять адреса не вижу. Профита мало - не такой уж великий труд набрать адрес заново, если вдруг врач становится пациентом, а минусов больше.
...
Рейтинг: 0 / 0
10.06.2016, 15:49
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254346
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
Завести справочник типов адресов (юр, физ, врем и т.п.) и любой персоналии можно добавлять хоть всех их с датой смены. То есть будет и история смены адресов.
...
Рейтинг: 0 / 0
10.06.2016, 16:00
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254404
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
zeon11Пациентов и персонал нужно хранить в разных таблицах
Дык это и было описано в стартовом посте :)

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

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

Мда, нет в мире совершенства ...
...
Рейтинг: 0 / 0
10.06.2016, 17:22
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254473
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
zeon11Например, есть таблица, доступ к которой имеют пользователи с разными функциональными обязанностями, пусть, если разговор о медицине, врачи и медсёстры. Причём какую-либо группу полей могут редактировать врачи, а медсёстры эту группу полей только просматривать. Можно конечно, благо FB позволяет, решить проблему назначением прав на каждое поле таблицы, а можно и просто эту группу вытащить в отдельную таблицу в отношении к родительской как 1:1 и уже этой отдельной таблице назначить права.
Для "дилетантов" есть более простой пример отношения 1:1, который "чересчур умные не дилетанты" понять вообще не в состоянии, так как у них от этого примера случается когнитивный диссонанс.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
CREATE TABLE "tree_ids"
(
    "id" ID NOT NULL,
  CONSTRAINT "tree_ids__pk" PRIMARY KEY ("id")
);

CREATE TABLE "tree"
(
    "id"      ID NOT NULL,
    "node_id" ID DEFAULT NULL,
    "name"    NAME NOT NULL,
  CONSTRAINT "tree__pk" PRIMARY KEY ("id"),
  CONSTRAINT "tree__fk__tree_ids" FOREIGN KEY ("node_id")
    REFERENCES "tree_ids" ("id") ON UPDATE CASCADE ON DELETE CASCADE
);

SET TERM ^;
CREATE OR ALTER TRIGGER "tree__TR_AI"
  FOR "tree"
  AFTER INSERT
  POSITION 0
AS
BEGIN
  INSERT INTO "tree_ids" ("id") VALUES (NEW."id");
END^
SET TERM ;^

ALTER TABLE "tree_ids"
  ADD CONSTRAINT "tree_ids__fk__tree" FOREIGN KEY ("id")
    REFERENCES "tree" ("id") ON UPDATE CASCADE ON DELETE CASCADE;
COMMIT WORK;


P.S. Прошу прощения, если где-то опечатка. Набирал прямо тут.
...
Рейтинг: 0 / 0
10.06.2016, 19:03
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254494
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Докzeon11Пациентов и персонал нужно хранить в разных таблицах
Дык это и было описано в стартовом посте :)

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

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

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

Док, зачем тебе ID клиники? Или медицинский холдинг описываешь?

А если по нормальному, то тут можно накрутить много чего. Ну, во первых, где специальность врача в момент приёма? Знаешь-же, сейчас он ортопед, а вечером он уже травматолог. А если он ещё и как зав. отделением принимает? вот уже ещё один ID.
...
Рейтинг: 0 / 0
10.06.2016, 19:51
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254539
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
zeon11,
это очень просто объясняется: я принимаю, как минимум, в двух клиниках (на три уже не хватает ни сил, ни желания). Базу ношу с собой на флешке. В конце рабочей смены вывожу отчет на печать с сформироваными итогами. Вот тебе и id клиники.

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

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

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

Я делаю новую базу на основе старой, которая была спроектирована более 7 лет назад. Очевидные огрехи исправляю. Увы, новые тоже появляются. Некоторая денормализация - вынужденная мера за универсальность, главное - чтобы во всем был разумный предел
...
Рейтинг: 0 / 0
11.06.2016, 02:17
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254578
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Док,
тут у тебя только учёт приёмов или ещё и амбулаторные карты в программе ведёшь?
...
Рейтинг: 0 / 0
11.06.2016, 10:00
| Ответить | Цитировать | Написать  
Фейковый FK
    #39254683
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
zeon11,

там пока в основном только амбулаторный прием и есть. По скринам можно примерное представление составить (прямых ссылок постить не буду, можно найти из профиля)
...
Рейтинг: 0 / 0
11.06.2016, 16:57
| Ответить | Цитировать | Написать  
Фейковый FK
    #39255468
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
zeon11Пациентов и персонал нужно хранить в разных таблицах, поскольку персоналом управляет сотрудник отдела кадров (ну, или там автоматический обмен с кадровой программой), а пациентами управляют медработники, соответственно к таблицам должны иметь доступ разные роли.вопрос легко решаем навешиванием пары вьюх.
...
Рейтинг: 0 / 0
14.06.2016, 09:19
| Ответить | Цитировать | Написать  
Фейковый FK
    #39255472
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
rdb_devЯ всё правильно осознал?На мой взгляд ты нихрена не понял. Обсуждение модераторских действий и перепалку я порезал.
...
Рейтинг: 0 / 0
14.06.2016, 09:25
| Ответить | Цитировать | Написать  
Фейковый FK
    #39255500
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Ivan_Pisarevsky... и перепалку я порезал.
"Хорошая мысля приходит опосля" (с) /народ/ ;)
...
Рейтинг: 0 / 0
14.06.2016, 10:11
| Ответить | Цитировать | Написать  
23 сообщений из 48, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Фейковый FK
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39254494&tid=1562137]:
 0ms
get settings:
 10ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 47ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 52ms
get tp. blocked users:
 1ms
others: 13ms
total:  152ms
созд. / загр.: 152ms
x
x
Закрыть


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