|
|
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Задача:Медицинская тематика. Имеется задача по формализации признаков детей находящихся в очень тяжелом и крайне тяжелом состоянии для облечения последующей работы и высвобождения времени от рутинной писанины. Самое главное, необходимость выборки конкретного ребенка для оценки его в динамике. Имеется массив признаков ,которые оператор будет заполнять в форме методом выборке. По предварительной работе полечается кроме больших таблиц еще и "куча" маленьких. Например: Таблица- Оценка по системам: Признак- Сознание, реакция на осмотр, судороги, цвет кожного покрова, сыпь, тургор мягких тканей и ще штук 50 признаков. Каждый признак имеет параметрические оценки: -1, 0, 1, 2, 3, 4, 5, 6, 7. Но описательные параметрические оценки для опретатора разные: Для сознания:Нет данных.Сохранено полностью.Оглушение.Возбуждение.Сопор.Кома поверхностная.Кома глубокая. Для реакции на осмотр:Нет данных. Адекватная. Снижена. Выраженное возбуждение или судороги.Пат. позотонические реакции.Отсутствует. В основную таблицу будет вносится числовое значение. Вопрос Правильно ли, есля я буду делать для каждого приизнака свою таблицу подстановки значения ?По моим примерным подсчетам их будет более 200. Насколько такие огромные массивы могут повлиять в последующем на быстродействие базы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 11:17 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
saj пишет: > Правильно ли, есля я буду делать для каждого приизнака свою таблицу > подстановки значения ? Видимо, нет. Надо делать одну таблицу, в PK которой будет входить тип признака. > Насколько такие огромные массивы могут повлиять в последующем на > быстродействие базы? слабо, при правильном проектировании БД. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 11:24 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Не понятно, как можно сделать одну таблицу, еслс на все 9 значений каждого признака разные описательные данные? Примерно 240.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 11:30 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajНе понятно, как можно сделать одну таблицу, еслс на все 9 значений каждого признака разные описательные данные? Примерно 240.... Очень просто. Например, будут таблицы: автор Признаки (ID признака, название) Значения признаков (ID признака,NUM_Value,String_value) В NUM_Value помещем числовые значения (-1,0,1 и т.д.), а в String_value - соответствующее текстовое описание для признака с конкретным ID призака. Итого получаем два файла. В одном будет <количество признаков> строк, в другом - "примерно 240"... Затем String_value используем для построения "человеческого" интерфейса (комбо-боксы, выдача в колонки отчета и т.д.), а NUM_Value - для хранения в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 11:42 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajВопрос Правильно ли, есля я буду делать для каждого приизнака свою таблицу подстановки значения ?По моим примерным подсчетам их будет более 200. Насколько такие огромные массивы могут повлиять в последующем на быстродействие базы? В свете вышесказанного "перекодировочные" таблицы будут получаться из "основной" по параметризованному запросу: Select * from <Значения признаков> where ID = <параметр - запрошенный ID> order by Num_value ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 11:49 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajЗадача:Медицинская тематика. .... Вопрос Правильно ли, есля я буду делать для каждого приизнака свою таблицу подстановки значения ?По моим примерным подсчетам их будет более 200. Насколько такие огромные массивы могут повлиять в последующем на быстродействие базы?Посмотрите в сторону EAV. Вот описание - здесь тоже медицинская тематика . У EAV есть серьезная проблема - это быстродействие. Коснется она вас или нет - зависит от того как все остальное спроектируете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 12:30 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Спасибо, попробую..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 13:11 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Пардон.... Это значит, что оператор должен будет выбирать значение для признака из 200 параметров? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 13:49 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajПардон.... Это значит, что оператор должен будет выбирать значение для признака из 200 параметров? Нет, из 9 для каждого признака: Станислав С...кий ... "перекодировочные" таблицы будут получаться из "основной" по параметризованному запросу: Select * from <Значения признаков> where ID = <параметр = запрошенный ID признака> order by Num_value Для EAV просто Select будет другой.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 13:56 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Если значения признаков состоят только из описания, то удобно завести одну таблицу-словарь вида (признак, код, описание). FK можно и не делать. Если с каждым признаком связаны какие то дополнительные атрибуты, кроме описания, то имеет смысл завести разные таблицы с соответствующей структурой. Например признаки цвета могут содержать значения области RGB, признаки сыпи фотограции образцов таковой и т.п.. В прочем и эти атрибуты можно попробовать свести в унифицированную структуру справочника и оценить ++ и -- от её использования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 05:29 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
в String_value - соответствующее текстовое описание для признака с конкретным ID призака.... Вся и беда то в том , что текстовые описания для каждого значеня в зависимости от признрка разные... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 12:24 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajв String_value - соответствующее текстовое описание для признака с конкретным ID призака.... Вся и беда то в том , что текстовые описания для каждого значеня в зависимости от признрка разные... Т.е Сознание sosnanie -1 Нет данных 0 Сохранено полностью 1 Оглушение 2 Возбуждение 3 Сопор 4 Кома поверхностная 5 Кома глубокая Судороги за последние 6 часов sudorogi -1 Нет данных 0 Отсутствовали 1 Фокальные неповоторяющиеся 2 Фокальные неповторяющиеся 3 Генерализованные повторяющиеся 4 Статус И.Т.Д ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 12:46 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajв String_value - соответствующее текстовое описание для признака с конкретным ID призака.... Вся и беда то в том , что текстовые описания для каждого значеня в зависимости от признрка разные... Sorry, а что, у Вас оценки всех признаков будут "биться" в одно поле записи?! Это не есть гуд для хранения в БД; это гуд только при выводе в отчет... Мое решение - делаем следующие таблицы для пациентов: Код: plaintext 1. 2. Если говорить более понятным языком, то получается как бы связка Регистрация - Спецификация (или Шапка документа - Спецификация), где в регистрации указывается постоянная часть "документа", а в спецификации - "переменная".... При этом, в спецификации может быть много строк... Возьмите и изучите любую счет-фактуру, чтобы понять принцип, о котором я говорю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 12:56 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
saj sajв String_value - соответствующее текстовое описание для признака с конкретным ID призака.... Вся и беда то в том , что текстовые описания для каждого значеня в зависимости от признрка разные... Т.е Сознание sosnanie -1 Нет данных 0 Сохранено полностью 1 Оглушение 2 Возбуждение 3 Сопор 4 Кома поверхностная 5 Кома глубокая Судороги за последние 6 часов sudorogi -1 Нет данных 0 Отсутствовали 1 Фокальные неповоторяющиеся 2 Фокальные неповторяющиеся 3 Генерализованные повторяющиеся 4 Статус И.Т.Д Ну и будет у Вас: 1. Признаки: Код: plaintext 1. 2. 3. 4. 5. 2. Значения признаков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 3. Пациенты Код: plaintext 1. 2. 4. Состояние пациента Код: plaintext 1. 2. 3. 4. 5. 6. Сейчас понятно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:10 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
В общей таблице для каждого признака свое поле, в которое должно попасть цифровое значение признака. Признаков много, а описаний ще больще потому, что они разные. Хотя ьаксимальная цифра значения признака 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:14 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Буду ваять. Переделывать все, не первый раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:17 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajБуду ваять. Переделывать все, не первый раз. Зачем же все? Немного доделать... То, о чем Вы говорите - это отчет/печатный документ. Это решается через таблицу для настройки (типа первая колонка - обозначает признак № 10, вторая - признак № 2 и т.д). Была у меня похожая задача, из бухгалтерии... Только там надо было еще считать итоги, типа строка_10+строка_20 или (колонка_1-колонка_2)*колонка_3... Оказалось - не так сложно, как казалось... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:28 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
А в форме выборку значения данного признака нужно сделать через связь признак - значения признака по его ID? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:43 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajА в форме выборку значения данного признака нужно сделать через связь признак - значения признака по его ID? Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:46 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
СПАСИБО ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:47 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
2. Значения признаков: ID признака NUM_Value String_Value 10 -1 Нет данных 10 0 Сохранено полностью 10 1 Оглушение 10 2 Возбуждение 10 3 Сопор 10 4 Кома поверхностная 10 5 Кома глубокая 20 -1 Нет данных 20 0 Отсутствовали 20 1 Фокальные неповоторяющиеся 20 2 Фокальные неповторяющиеся 20 3 Генерализованные повторяющиеся 20 4 Статус 30 -1 Нет данных Может быть добавить 4 столбец, как обозначение признака? ID признака NUM_Value String_Value Name_Value 10 -1 Нет данных Сознание 10 0 Сохранено полностью Сознание ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 13:51 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
saj2. Значения признаков: ID признака NUM_Value String_Value 10 -1 Нет данных 10 0 Сохранено полностью 10 1 Оглушение 10 2 Возбуждение 10 3 Сопор 10 4 Кома поверхностная 10 5 Кома глубокая 20 -1 Нет данных 20 0 Отсутствовали 20 1 Фокальные неповоторяющиеся 20 2 Фокальные неповторяющиеся 20 3 Генерализованные повторяющиеся 20 4 Статус 30 -1 Нет данных Может быть добавить 4 столбец, как обозначение признака? ID признака NUM_Value String_Value Name_Value 10 -1 Нет данных Сознание 10 0 Сохранено полностью Сознание Зачем? Это Name_Value уже есть в таблице Признаки. Эту "таблицу" получаем запросом: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 14:03 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
автор 2. Значения признаков : ................................................ 20 1 Фокальные неповоторяющиеся 20 2 Фокальные неповторяющиеся ................................................. исправить надо !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 14:32 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
Станислав С...кий Мое решение - делаем следующие таблицы для пациентов: Код: plaintext 1. 2. 1. От ID признака в Состоянии пациента можно и нужно (в силу избыточности) легко избавиться. 2. Предложенная EAV модель данных красиво смотрится, но увы плохо работает в реляционной СУБД. Если не стоит задача динамически создавать новые признаки, то в реляционной БД следует создать для каждого значения признака отдельную колонку в таблице состояния, иначе получение общего состояния пацианта из отдельных записей-признаков скоро станет неподъёмной задачей для СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2008, 02:04 |
|
||
|
Правильный подход к созданию базы. НУЖЕН СОВЕТ
|
|||
|---|---|---|---|
|
#18+
sajПравильно ли, есля я буду делать для каждого приизнака свою таблицу подстановки значения? Cкорее всего, правильно. sajНасколько такие огромные массивы могут повлиять в последующем на быстродействие базы? В принципе, конечно, если очень постараться, на любой базе можно добиться отвратительного быстродействия, но во-первых, здесь нет огромных массивов, во-вторых, вряд ли это хоть как-то повлияет на быстродействие, и наконец, благодаря специфике предметной области, я так думаю, объем данных, способный реально тормозить на относительно современном железе, вы наберете очень и очень нескоро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2008, 03:10 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35126486&tid=1544026]: |
0ms |
get settings: |
5ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
174ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
75ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 502ms |

| 0 / 0 |
