Проэктирование базы

← →
jack128 © (2003-03-31 18:16) [0]

Это моё первое приложение базы банных, и вот возник такой вопрос:
Есть несколько типов устройств, которые хранят определенные архивные данные,
нужно эти данные собрать и хранить в базе. Так структура архивов у разных устройств различна , то хранить их в одной таблиц проблематично.К тому же в будущем созможно понадобится поддержка других устройств, а которых я ещё ничего не знаю.
В связи с этим я вишу два подхода
а) Хранить архивные данные для всех устройств в BLOB полях, и анализировать на клиенте (
таблица вида
DateTime timestamp nto null,
DeviceID integer, /* ссылка на устройство*/
Data BLOB(100))

б) Для каждого типа устройств создавать свою таблицу архивов

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

← →
AleksandrKu (2003-03-31 18:41) [1]

ну 2 способ конкретно неприемлем а почему тебе ненравиться 1 способ что тысэтими данными хочешь делать?

← →
MsGuns © (2003-03-31 18:56) [2]

Обычно сначала конретизируются ОБЪЕКТЫ, затем их свойства. После этого устанавливаются связи между объектами. После чего выясняется, каким требованиям все это хозяйство должно удовлетворять. И только после этого на прототип модели накладываются условия (например, какие формы, отчеты и т.д. должны быть).

В твоей проблеме я увидел только одва объекта:
- Архив (неизвестно чего, но опускаем пока)
- Носитель (тоже неясно, магнитный что ль ?)

Группы (типы) носителей, виды (категории) архиров есть не объекты как таковые, а лишь свойства самих объектов, поэтому могут быть выражены лишь в справочном виде.

>а) Хранить архивные данные для всех устройств в BLOB полях

Зачем блобы ? Чтоб хранит строки по 100 символов ? Поиск и выборка по блоб-полям существенно усложняет логику и снижает производительность всей системы. Непонятно.

>и анализировать на клиенте
Еще нет даже в проекте БД, нет никакой ясности с моделью и бизнес-логикой, а уже оперируем понятием "На клиенте" ?

← →
jack128 © (2003-03-31 21:46) [3]

Оки, конкретизируем
Устройства - это вычислители тепловой энергии. Они хранят некие параметры(теплая энергия,объем горячей, холодной воды и тд за сутки), архив вычислителей ограничен(обычно порядка двух месяцев) - соответственно есть желание эти данные сохранить на компе, чтобы в любой момент просмотреть, распечатать данные за любой период.
Проблема в том, что разные вычислители (разные типы вычислителей) хранят разные параметры(например вычислитель типа А хранит только тепловую энергию и объем горячей воды, вычислитель типа В хранит температуру горячей и
холодной воды), поэтому свести все это в одну таблицу можно только в виде блобов.

То есть в Вашей терминалогии, если я правильно понял :

Есть объект Устройство, которое характеризуется свойствами :
- тип устроуства
- код устройства(некое число, записываемое в устройство при производстве)
- местоположение устройства
и тд. Все это легко сохранить в таблице

И есть объект архив устройства. И вот тут облом. Для каждого типа устройств архив имеет свои свойства

>>Зачем блобы ? Чтоб хранит строки по 100 символов ?

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

>>>Еще нет даже в проекте БД, нет никакой ясности с моделью и бизнес-логикой, а уже оперируем понятием "На клиенте" ?

Ещё раз повторюсь, это мая первая база данных, и я ещё плохо представляю с какой стороны за неё браться

← →
jack128 © (2003-03-31 21:51) [4]

AleksandrKu (31.03.03 18:41

> а почему тебе ненравиться 1 способ что тысэтими данными
> хочешь делать?

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

Конкретика еще никогда делу не мешала :)
Итак, есть третий объект: параметры замеров. Можно итти 2-мя путями: с нормализацией и без.

С нормализацией.
Если все ВИДЫ замеров (т.е.кол-во тепла а ККал, объем воды в кубах и т.д.), производимые ВСЕМИ видами счетчиков (устройства+вычислители) можно привести к единому ряду (при этом не важно, имеет ли любой конкретный счетчик ВСЕ виды замеров или нет, главное, чтобы все однородные показатели, например, кол-во тепла, приводились к одной единице), то имеем доп.объект-свойство - ВИД ЗАМЕРА, которых у любого счетчика может быть сколько угодно, но все разные ! Инфа будет собираться по счетчикам с раскладкой по видам замеров. При этой методе не надо никаких строк и тем более мемо - все должно преобразовываться на этапе "укладки" данных из входного потока в БД.

Без нормализации.
Немного хуже, но тоже оборимо. Для каждого типа счетчика заводим "дерево", каждый лист которого (дерево двухэтажное) несет в себе линейную инфу: текст, идентифицирующий вид замера, и собственно величину замера. Конечно, вычисления над подобными "кустами" усложнены, т.к. требуют значительных затрат на семантическую алгоритмизацию (отделения чисел, распознавания ед.измерения, приведение к некоторой счетной единице и т.д.), но совсем не обязательно делать это "на клиенте". Можно и на сервере, правда придется попотеть над ХП или UDF, но это уже вопрос чисто технический.

То есть это будет выглядить примерно так :
DateTime - дата и время , когда сняли этот параметр
ParamType - вид замера - тепло или температура или объем или ...
DeviceID - id устройства, с которого снят данный параметр
Value - значение параметра
ParamNumber - номер данного параметра(вычислители могут измерять несколько параметров данного "вида замера", например 1 - температура холодной воды, 2 - температура гогрячей воды )
Если я правильно понял...

Проэктирование базы Найти похожие ветки