Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.02.25;
Скачать: CL | DM;

Вниз

Создание структуры БД. Что лучше?   Найти похожие ветки 

 
ulyanitsky ©   (2004-01-25 22:09) [0]

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

Вопрос: что лучше
1) в БД создать 124 таблицы, которые привязать к главной
или
2) программно задавать список значений полей в DBGrid"e (напр. EhDbGrid), а в базе - 1 таблица с порядковыми номерами значений?


 
Плохиш_   (2004-01-25 22:39) [1]

1.
но сначала хорошо подумать над структурой, нужно ли 124 таблицы или можно некоторые объединить, к примеру.


 
ulyanitsky ©   (2004-01-25 22:52) [2]

Вот в чем изюминка - данные никак нельзя объединить (от роста до последних месячных...)

Если использовать второй вариант, то нет ли программного средства, специально предназначенного для этого?


 
Sergey_Masloff   (2004-01-25 23:15) [3]

ulyanitsky © (25.01.04 22:52) [2]
>Вот в чем изюминка - данные никак нельзя объединить (от роста >до последних месячных...)
Ну и почему нельзя? Можно и легко.


 
kaif ©   (2004-01-25 23:23) [4]

Второй вариант использовать неправильно. Но если очень хочешь, то для этого просто хранишь все эти Lookup-таблицы местно в каких-нибудь dbf-ах или текстовых файлах.
Но повторюсь, так неправильно. Нет никакого смысла отказываться от 1-го варианта. Если тебя пугает объединение 124 таблиц, то можно написать хранимую процедуру, в которой будет лежать этот жуткий SELECT. Или 10 хранимых процедур, в которых лежат SELECT-ы, объединающие по 12 таблиц, а приложение объединяет результаты в одном общем SELECT (хотя это некрасивое решение). И я уверен, что если имена таблиц короткие, то простой INNER JOIN 124 таблиц - не проблема.
То есть хранить данные в 124 таблицах правильно. Другой вопрос, стоит вообще запрашивать все поля одновременно? И стоит ли объединение делать всегда на сервере? Я не исключаю, что имеет смысл, несмотря на то, что все данные лежать на сервере, при старте приложения скачать все мелкие lookup-таблицы в некий локальный кэш, реализованный, например, на основе таблиц в памяти, dbf-ов или датасетов, работающих с локальными текстовыми файлами. Это может ускорить работу такого приложения, так как объединять все 124 таблицы никогда на практике просто не придется.


 
Ulyanitsky ©   (2004-01-28 22:48) [5]

Решено делать так: 2 таблицы.
1-я - Справочник (VocID, FieldID, FieldValue)
2-я - Фамилия + 124 поля (VocID из справочника).
В справочнике значения хранятся как строки.

В DBGrid показываются 124 поля.
Когда пользователь хочет выбрать значение из списка в ячейке (LookupField) - включаем фильтр по номеру поля FieldID - показываются только нужные значения.
По-моему оптимальный вариант. Или есть другие оптимальные варианты?
Есть еще вопросик: как сдесь лучше сортировку сделать?


 
Sergey_Masloff   (2004-01-28 23:20) [6]

Вариант абсолютно плохой. 124 поля в твоем случае - это просто никудышный дизайн. 1 таблица - сабджекты (больные, врачи - все) 2 - я таблица DETAIL к 1 - параметры. В ней от 0 до 124 записей - по потребности. 3-я таблица справочник иерархический. В него можно поместить ВСЕ и для этого понадобится (вместе со служебными) не более десятка полей. Некоторые ветки иерархии можно расшить отдельными таблицами но не думаю что их будет много.


 
ЮЮ ©   (2004-01-29 03:22) [7]

>данные никак нельзя объединить (от роста до последних месячных...)

А что ты пониаешь под "последними месячными" у мужчин ?
А если какие-то параметры нужны будут в динамике? Например, все месячные за год наблюдения? Неужели и рост при этом у женщин меняется?



Страницы: 1 вся ветка

Текущий архив: 2004.02.25;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.036 c
1-79958
WebErr
2004-02-13 18:59
2004.02.25
Как динамически выделить память под двумерный массив?


14-80243
Soft
2004-02-04 17:55
2004.02.25
Microsoft запатентовал работу с XML.


3-79542
GSVSerg
2004-02-03 11:55
2004.02.25
Новая запись в НД


6-80061
Term!
2003-12-19 12:22
2004.02.25
Не работает Win-CGI приложение


3-79651
OlegM
2004-02-02 12:46
2004.02.25
Автоинкрементное поле в таблицах dBase