Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Создание структуры БД. Что лучше?

ulyanitsky © (2004-01-25 22:09:00)

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

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

ЮЮ (2004-01-29 03:22:00) [1]

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

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

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

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

Ulyanitsky (2004-01-28 22:48:00) [3]

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

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

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

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

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

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

ulyanitsky (2004-01-25 22:52:00) [6]

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

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

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

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »