Классика. Нет тз. Он не знает что выбрать

Можно монетку подкинуть

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

пока склоняюсь к четвертому типу

Я сейчас по типам не помню, но смысл в том, что если классические реляционки, то в большинстве своем удобно по двум полям: start и end. По одному полю выгодно, если БД колоночная и если есть хорошие аналитические функции, чтобы вынимать данные по этому одному полю

пока склоняюсь к четвертому типу

6. Обсуждали уже на днях. Валишь все в кучу. Выбираешь селектом по имени клиента и дате

Ну и еще стоит учесть, что по одному полю очень геморно иногда писать запросы, т.к. надо делать под запросы, тогда как по двум полям достаточно просто условия

а при этом ссылочной целостности мы машем ручкой и прощаемся в внешними ключами, верно?

Это очень важный момент, если надо потом данные распихивать на уровне какого-нибудь ORM или стандартизированного ETL

а при этом ссылочной целостности мы машем ручкой и прощаемся в внешними ключами, верно?

Зачем чему то махать?

У меня такое впечатление что большинство людей воспринимают примеры решений как конечный паттерн в который нельзя вносить изменения под страхом импотенции

Заведи еще 100500 колонок и размещай в них ключи и ссылки и что там еще зачешется. Можешь даже даты в юникc тайм записывать. Что бы в условиях выборки проще искать. 3456 <t <456788

ну нет, все не так страшно. смотрите, приведу пример. у меня есть пациенты,чьи контракты (документы, полисы) версионируются. грубо говоря, есть таблица в которой у одного пациента есть записи вида patid, stamp. есть контракты этого пациента вида conid, stamp, patid. ссылка осуществляется не на конкретную версию пациента, а просто на его идентификатор, так как карта пациента и его контракты меняются в разное время. в данном случае внешний ключ создать нельзя

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

первый вариант хоронит uuid, второй - лишняя таблица для каждой версионируемой сущности

Пойду застрелюсь

хи) а перед смертью прощальную записку не напишите по моему вопросу?

Я написал уже

Но у вас же свои варианты. Это типа прошу помощи, но делать буду вот так.

пока склоняюсь к четвертому типу

Так надо адаптивно принимать решение по каждому атрибуту, который меняется, в соответствии с ТЗ, потому что я думаю смену ФИО можно и перезаписать, а смену полиса явно надо жёстко хранить.

Так надо адаптивно принимать решение по каждому атрибуту, который меняется, в соответствии с ТЗ, потому что я думаю смену ФИО можно и перезаписать, а смену полиса явно надо жёстко хранить.

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

Анахрена их вообще искать в аналитической базе?

Так надо адаптивно принимать решение по каждому атрибуту, который меняется, в соответствии с ТЗ, потому что я думаю смену ФИО можно и перезаписать, а смену полиса явно надо жёстко хранить.

Нужно просто завести одну таблицу на все. И выбирай например по номеру полиса. Будет 2 фамилии на один номер полиса значит сменила увидишь когда

И так далее

Анахрена их вообще искать в аналитической базе?

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

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

если у нас и дальше будут сокращать за год 63к конек в больницах и врачей, то эта система скоро не понадобится

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

Тогда при чем тут Slowly Changing Dimensions ?

Ну все равно в бд надо решать про все атрибуты индивидуально

ФИО - текущее в таблице справочнике и в отдельной таблице Алиасы с датами.

Тогда при чем тут Slowly Changing Dimensions ?

Слова понравились

Тогда при чем тут Slowly Changing Dimensions ?

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

если у нас и дальше будут сокращать за год 63к конек в больницах и врачей, то эта система скоро не понадобится

Ты хохлосрачь тут устроить собираешься?

что же это, если не scd?

что же это, если не scd?

Кривые руки?

Денис, просто как подходы это рассмотреть можно

Влажные фантазии?

Ты хохлосрачь тут устроить собираешься?

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

ФИО - текущее в таблице справочнике и в отдельной таблице Алиасы с датами.

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

Но там половина из тех типов отпадут у тебя просто потому что у тебя бд не склад данных, а оперативная

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

Зачем в одной? Не ну дело твоё, надо задачу знать, чтобы что-то советовать

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

Предлагаю за оффтопик варн

Кривые руки?

а если конструктивно, что не так? я серьезно, поправьте лучше сейчас

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

/warn

а если конструктивно, что не так? я серьезно, поправьте лучше сейчас

Денис, так ТЗ надо читать твоё, в задачу вникать

Денис, так ТЗ надо читать твоё, в задачу вникать

????????? тз в госах?

ну ты хоть так не смеши

а если конструктивно, что не так? я серьезно, поправьте лучше сейчас

Блин я отказываюсь в 3 раз повторять.

Без этого можно только пальцем в небо тыкать

Без этого можно только пальцем в небо тыкать

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

вообще вопрос изначально был - кто делал что-то похожее на scd и какие подводные камни были, поделитесь опытом. а вы пытаетесь решить мою задачу сейчас

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

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

Ну, я поделился

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

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

есть хотелка, но тз нет

Ну, я поделился

благодарю

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

Так вон оно че Михалыч. Это обьясняет че оно все такое..

А подводные камни известны, надо чтобы всегда была возможность выдать данные на сейчас и на дату в прошлом, при этом чтобы делалось это оптимальным для 80 % задач образом

Так вон оно че Михалыч. Это обьясняет че оно все такое..

так а как ещё? самое прикольное, что системы по ндс, егаису и куче ещё вещей обслуживают инженеры за 35к

сервис недел лежит, да и ладно

Так вон оно че Михалыч. Это обьясняет че оно все такое..

А типа сесть и самому написать ТЗ конечно день, Пушкин же у нас ТЗ пишет всегда...

А типа сесть и самому написать ТЗ конечно день, Пушкин же у нас ТЗ пишет всегда...

а кому твоё тз надо? будет понедельник сядут 6 дядь и скажут, нравится им или нет, если нет - переделывай

А типа сесть и самому написать ТЗ конечно день, Пушкин же у нас ТЗ пишет всегда...

Зачем мне самому писать тз для заказчика. Пусть оплачивает я ему войну и мир напишу.

так а как ещё? самое прикольное, что системы по ндс, егаису и куче ещё вещей обслуживают инженеры за 35к

Большая честь же

Большая честь же

честь не честь, а я уже пол года на это смотрю

а кому твоё тз надо? будет понедельник сядут 6 дядь и скажут, нравится им или нет, если нет - переделывай

Ты как бы ежели не нравится, не стесняйся, увольняйся...

Ты как бы ежели не нравится, не стесняйся, увольняйся...

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

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

А чего тогда в разговоры серьезные вмешиваешся?т

Ты то один, не 80тыщ

А чего тогда в разговоры серьезные вмешиваешся?т

а чем он закончился, требованием от человека того, чего у него не будет?

а чем он закончился, требованием от человека того, чего у него не будет?

Человек хочкт создавать динамически таблички на каждого пациента

Он считает это вариантом

Человек хочкт создавать динамически таблички на каждого пациента

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

Человек хочкт создавать динамически таблички на каждого пациента

Не ну это бред

Человек хочкт создавать динамически таблички на каждого пациента

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

первый вариант хоронит uuid, второй - лишняя таблица для каждой версионируемой сущности

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

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

так и в чем я не прав? Даешь каждому пациенту отдельную таблицу

первый вариант хоронит uuid, второй - лишняя таблица для каждой версионируемой сущности

помимо этого я рассматривал вариант двух таблиц, где в первой одна колонка patid с первичным кключом ( на нее все ссылаются), во второй - версии этого patid. но это не история про динамические таблицы на каждого пациента

так и в чем я не прав? Даешь каждому пациенту отдельную таблицу

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

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

Вот и мне интересно

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

Опасно. Но это зависит от твоей архитектуры приложения, потому как может у тебя там 20 проверок перекрёстных по данным до того, как всё это попадает в БД...

Но я вообще не понимаю постановку вопроса : почему ты должен от FK отказываться? Что мешает их делать всегда ?

Ну смотри, есть две таблицы - пациенты и контракты пациентов. В таблице пациенты первичный ключ, допустим, (patid, stamp). В таблице контрактов условно три колонки - conid, stamp, patid. Первичный ключ - (conid, stamp), поле patid должно по идее ссылаться на пациентов в виде внешнего ключа, но не может, так как в таблице пациентов уникален лишь составной ключ (patid, stamp). Я думал для каждой версионируемой таблицы создавать ещё одну, например «уникальные id пациента» с первичным ключом patid, но это overhead, да и такие конструкции слишком много где жегородить придётся

В таблице пациенты первичный ключ, допустим, (patid, stamp). Почему такой-то ?

Ты же на пациента контракт заводишь, а не на его паспортные данные ...

Нет, у тебя всё не так.

Тебе надо сделать одну таблицу пациентов, и там хранить неменяющиеся со временем данные, и к ней создать дочернюю таблицу, 1:N, где будут периоды действия данных и данные, которые ты будешь менять со временем.

Ссылаясь на поциэнта, ты должен ссылаться на главную таблицу с (patient_id) в виде ключа. Ссылаясь на какие-то его данные — уже на дочернюю с ключём (patient_id, ...)

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

Вряд ли, но путь так

Дата рождения, напр. не будет меняться.

Поверь, так. Дата рождения - это атрибут паспорта. Можно радикально все менять

бл.. я име ю в виду биологическое рождение, а не по паспорту

Я понимаю, что молодуха может себе написать, что ей 38 а не 55, но от этого климакс у неё не остановится...

По паспорту это вообще в отдельных таблицах должно быть, документы, паспортные данные. и т.п.

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

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