|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
Доброго дня. Есть задача - хранить результаты анализов человеческих в БД. Проблема - тип результата анализа непостоянный и должен контролироваться допустимыми пределами, а в идеале, еще и определять норма/ниже нормы/выше нормы. Результат может быть int, float, text, список значений. Например - цвет мочи - он из списка значений, температура - это флоат, пульс - инт и т.п. Планирую хранить в виде <ИД типа анализа><Значение анализа:текст> и в тексте хранить все. Только как потом это редактировать? В гриде ж можно только 1 тип указывать - как сделать, что в зависимости от типа анализа (точнее типа нужного результата) подставлять в грид либо комбобокс, либо TextEdit, либо NumberEdit? Планирую задействовать девок и вертикалгрид, но набор параметров разный - анализ крови - один набор параметров, анализ мочи - другие... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 19:36 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin, Вы с вопросом выбора СУБД не можете определиться? Так любая подойдет, задачи то у вас простейшие. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 19:39 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin в тексте хранить все GrigoriyFomin Например - цвет мочи - он из списка значений GrigoriyFomin температура - это флоат GrigoriyFomin <ИД типа анализа><Значение анализа:текст> ID Анализа Тип измерения Значение (например NUMERIC(18, 6)) По типу измерения проводить валидацию ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 19:45 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
_Vasilisk_, а простой текст как хранить? НАпример ">15%" ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 20:01 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 20:10 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin _Vasilisk_, а простой текст как хранить? НАпример ">15%" ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 20:18 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin а простой текст как хранить? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 20:56 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
_Vasilisk_ GrigoriyFomin а простой текст как хранить? да я добавлю хоть десяток полей под каждый тип - как это в ГУЕ реализовать? хочется, как в ObjectInspector - у каждого параметра свой редактор в зависимости от типа, но там RTTI - вагон самогона надо, чтоб понять и реализовать - куча ссылок на ссылки - это сишная шняга мозг выносит кому угодно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 22:50 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin хочется, как в ObjectInspector Код: pascal 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2021, 23:20 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
_Vasilisk_, Кстати, на последнем скриншоте в вышеприведённой статье оно типа такого что-то и есть. Только 20 лет назад, очевидно, ничего такого готового доступного не было. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2021, 00:27 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
Я бы не валил всё в кучу, а разносил отдельные анализы по разным таблицам и разным UI. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2021, 00:44 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Я бы не валил всё в кучу, а разносил отдельные анализы по разным таблицам и разным UI. Дим, так не интересно :( Надо сначала все в кучу обязательно. А уже потом, лет через - разбираться нафига оно было так сделано :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.08.2021, 21:08 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin, не надо тут никаких объектов и деревьев. Потому что их просто нет. Есть параметры крови, есть параметры мочи. Это отдельные сущности со своим набором параметров. В базе это хранится как отдельные таблицы. При чем, тут их всего ДВЕ таблицы. Городить объектное хранилище ради этого - боже упаси. GrigoriyFomin Результат может быть int, float, text, список значений. да не может. Цвет это всегда цвет, он не может превратиться во что-то другое. Это в карман себе вы можете всякого напихать. А у крови и мочи список параметров постоянный, и тип этих параметров давно известен. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 11:44 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
kdv, а кто говорил, что анализа всего два? Это лаборатория - составы анализов - вещь динамичная. Сегодня одни наборы, завтра закупят реактивы или новую машину - и появятся новые показатели. Поэтому это должно быть универсальное решение ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 12:52 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
Значит добавишь в таблицу новые поля или новые таблицы под новые анализы. О том, чтобы нагружать пользователей универсальным интерфейсом лучше забудь, у них своя работа есть, а продираться сквозь твои изыски - нет времени. "Реактивы и машины" не из воздуха материализуются, поэтому работай на опережение, добавляй не только анализы проводимые сейчас, но и те, что могут начать делаться позже. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 13:08 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFominПоэтому это должно быть универсальное решение совсем нет. Вас почему-то путает необходимость работы с разными источниками (моча, кровь, ...). Вы внезапно наделяете эти источники "разным количеством и типом параметров", хотя это не так. Кровь это кровь, у нее известен только один набор характеристик. А значит это один объект, с явным количеством параметров. Нет никакой нужды каждый замер крови хранить как отдельный объект. У "объектных хранилищ" самая больная мозоль - это производительность и сложность запросов, которыми вытаскиваются данные. Я понимаю, что вам хочется "замутить что-нибудь эдакое, интересное", но нет, не надо этого делать. И потом, данные из обычных, "плоских" таблиц можно вполне выводить в иерархическом виде. Только тут это нафиг не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 13:31 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin Поэтому это должно быть универсальное решение Универсальное решение: Код объекта исследования (Кровь, моча и т.д.); Код исследования; Код показателя; Значение. И справочники объектов исследования, типов исследования, показателей (с референсными значениями). И не каких больше, меньше. Всегда можно сделать выборку и группировку больше(меньше) по сравнению с референсным значением, ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 15:13 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin Поэтому это должно быть универсальное решение Код: sql 1.
1. Каждый тип анализа - класс для сохранения/загрузки xml-документа. В каждом таком классе классовое свойство (метод) отвечающий типу анализа. 2. Менеджер классов, выбирающий нужный класс, для сохранения/загрузки анализов по типам из таблицы. Например: Код: pascal 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.
Дальше полет фантазии. Но, вроде, идея должна быть понятна... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 17:08 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
Virtual Student Код: pascal 1.
Дальше полет фантазии. PS Про полет фантазии тут тоже очень к месту. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 18:55 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin, Моё видение (без погружения в предметную область, т.е. на вскидку) такое. По таблицам в БД. Первая группа - описательная (справочники): - 1.1 виды биоматериалов (кровь, моча и т.п.) - 1.2 типы анализов (общая биохимия, специфичная) - возможно дочерняя к 1.1 - 1.3 типы показателей (цвет, хим. элемент и т.п.) - дочерняя к 1.1 - 1.4 применимость показателей к конкретному типу анализа (многие-ко-многим между 1.2 и 1.3) Вторая группа - предметная (анализы) - 2.1 документ (анализ: вид, тип, дата, ФИО и т.п.) - 2.2 показатели - дочерняя к 2.1 (показатель, значение) Далее самое интересное, 1.3 должна описывать тип значения показателя - целое/вещественное/выбор и справочника/произвольный текст и т.п., допустимые границы (для ограничения пользовательского ввода, чтобы пользователь в принципе не мог ввести бред). Нормы значений (верхняя/нижняя граница нормы) - наверное на уровне 1.4 (либо и на уровне 1.3 - как умалчиваемая норма, так и на уровне 1.4 - как норма для конкретного типа анализа) Таблица 2.2 - это просто пара вида атрибут = значение (ессно со ссылкой на "объект" и возможно доп. комментариями). Для простоты я бы значения хранил просто в текстовом столбце (вряд ли нужна будет какая-то крутая аналитика по всем анализам от разных людей), но обязательно в фиксированном для каждого типа значения формате (типа если число - то без пробелов и точка как разделитель) с валидацией при вводе. Для визуализации можно использовать любой грид, который позволяет при редактировании значения создавать свой контрол для ввода значения, и уже динамически от типа редактируемого значения можно создавать TEdit/TNumberedEdit/TCombobox/TCheckBox и т.п. (Я такое делал в VirtualTreeView + едиты из EhLib - кода не мало, но работает на ура.) А по поводу сложности построения запросов - да, запросы писать не удобно, но: а) никто не мешает написать функцию вида get_attr_value(object_id, attr_id) б) проще сделать N-представлений (вьюх или запросов, которые можно строить динамически по описательной части), чем N-таблиц и всё равно N-запросов к ним. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 21:50 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
Всем спасибо за участие, особенно понравились идеи и примеры от Virtual Student и delphinotes !!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2021, 21:56 |
|
Подоскажите идею - хранение в БД разных по типу сущностей и удобная работа с ними
|
|||
---|---|---|---|
#18+
GrigoriyFomin, да. "create table [anal]" - это пять. Вообще, вам надо было сразу сюда https://www.sql.ru/forum/db-design Но я сразу могу сказать - таблица в БД с основными данными в xml - это хрень полная. То есть, это значит, что по всем параметрам анализов не предполагается проводить какие-то статистические или поисковые функции. Сколько самих анализов вообще предполагается хранить в этой БД? Искали вы уже примеры реализации хранения в БД анализов такого типа? И т.д. А так, если заняться нечем - самообразование всегда полезно, независимо от отрицательного или положительного результата. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2021, 01:00 |
|
|
start [/forum/topic.php?fid=58&msg=40089440&tid=2037121]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
141ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 246ms |
total: | 474ms |
0 / 0 |