Добрый день.

При разработке информационной системы возник очень "щепетильный" вопрос, а точнее проблема, и заключается она вот в чем.

В системе есть набор объектов, который имеет определенные параметры.
Информация о каждом параметре представлена в виде 3 характеристик:

1. Название параметра
2. Значение
3. Видимость параметра.

Если бы у объекта количество этих параметров было бы фиксированно, то можно было бы хранить каждый в отдельном поле. Но проблема заключается как раз в том, что количество параметров может меняться. Естественно создавать новый поля для существующих таблиц не приемлемый вариант, да и к тому же потом менять клиент, который будет работать с базой этих объектов тоже нельзя.

Собственно вопрос заключается в следующем: В каком виде, можно хранить такую информацию, чтобы соблюдалось несколько условий:

1. Количество параметров может меняться, причем меняться для всех объектов, существующих в системе.
2. Должна обеспечиваться простота выборки и редактирования существующих параметров.
3. Производительность должна быть на высоком уровне при обработке множества объектов.

?

з.ы.

Расматриваются 2 варианта:

1. Хранить все в виде xml в поле типа xml (SQL Server 2005).
2. Создавать отдельную таблицу со структурой object_id, param_name, param_value, is_visible.

Какие будут рекомендации?!!

Станислав С raptor@x-plat.ruДобрый день.

При разработке информационной системы возник очень "щепетильный" вопрос, а точнее проблема, и заключается она вот в чем.

В системе есть набор объектов, который имеет определенные параметры.
Информация о каждом параметре представлена в виде 3 характеристик:

1. Название параметра
2. Значение
3. Видимость параметра.

Если бы у объекта количество этих параметров было бы фиксированно, то можно было бы хранить каждый в отдельном поле. Но проблема заключается как раз в том, что количество параметров может меняться. Естественно создавать новый поля для существующих таблиц не приемлемый вариант, да и к тому же потом менять клиент, который будет работать с базой этих объектов тоже нельзя.

Собственно вопрос заключается в следующем: В каком виде, можно хранить такую информацию, чтобы соблюдалось несколько условий:

1. Количество параметров может меняться, причем меняться для всех объектов, существующих в системе.
2. Должна обеспечиваться простота выборки и редактирования существующих параметров.
3. Производительность должна быть на высоком уровне при обработке множества объектов.

?

з.ы.

Расматриваются 2 варианта:

1. Хранить все в виде xml в поле типа xml (SQL Server 2005).
2. Создавать отдельную таблицу со структурой object_id, param_name, param_value, is_visible.

Какие будут рекомендации?!!
Я склоняюсь ко второму варианту в несколько видоизмененной форме:


Не пойдет каждый объект имеет свое значение is_visible :)

тогда вот так
Параметры (param_id, param_name)
Значения (object_id, param_id, param_value, is_visible)

здесь получается нужно хранить много информации, а хотелось бы обойтись минимальными издержками при связывании таблиц.

Bogdanov Andrey raptor@x-plat.ruРасматриваются 2 варианта:

1. Хранить все в виде xml в поле типа xml (SQL Server 2005).
2. Создавать отдельную таблицу со структурой object_id, param_name, param_value, is_visible.

Какие будут рекомендации?!!

Подобные вопросы не раз тут обсуждались. Оба варианта имеют существенные недостатки. Например, отсутствует типизация параметров. Точнее ее можно реализовать но не средствами СУБД, а средствами приложения. Большие проблемы и с поиском по значениям параметров. С xml это вообще под снег, а во втором случае это можно сделать ззапросом, но запрос, который ищет объект по значениям пяти параметров уже тяжеловат для оптимизации.
Если количество параметров меняется не так часто и есть возможность типизировать объекты по количеству и видам параметров, то лучше в динамике создавать таблички и добавлять/удалять колонки. В этом случае есть возможность их избирательно индексировать, навешивать ограничения и т.п.

авторэто вообще под снег

Что это значит?!! :)

Станислав С raptor@x-plat.ru
Не пойдет каждый объект имеет свое значение is_visible :)

тогда вот так
Параметры (param_id, param_name)
Значения (object_id, param_id, param_value, is_visible)

здесь получается нужно хранить много информации, а хотелось бы обойтись минимальными издержками при связывании таблиц.
Это была просто декомпозиция/нормализация предложенной таблицы. Информации здесь будет нисколько не больше, чем в денормализованной (=первоначально предложенной) таблице.

В денормализованной таблице будут наблюдаться помимо аномалий обновления трудноуловимые ошибки, связанные с тем, что человек должен будет для одинаковых параметров для разных изделий снова и снова руками писать название. И в этом случае ошибиться легче, чем при выборе значения из справочника. Например, один оператор напишет "длина", другой - "длинНа", третий - "длЕна". Потом замаетесь эти ошибки разгребать и унифицировать наименования парамтров....

Да это все понятно... я просто вас немного подравил, в рамках своей задачи. :)

Господа тема сейчас не про приложение, а про данные...

Bogdanov Andrey raptor@x-plat.ruГоспода тема сейчас не про приложение, а про данные...

Если Bogdanov Andreyесть возможность типизировать объекты по количеству и видам параметров, то
список типов объектов:
table Types(TypeId integer)
список свойств объектов:
table Props(PropId integer,Name char,Table_name char,Column_Name char,<описание типа данных и т.п.>)
использование свойств типами:
table PropUse(PropId integer,TypeId integer)
При добавлении нового свойства в таблицу Props автоматически создается таблица
Table_name(ObjId integer, Column_Name char)
Если таблица уже есть, то в нее добавляется колонка.

Зная тип объекта, сформировать запрос, который вытащит значения всех свойств - не проблема.

Спасибо. То что нужно! :)!

mir raptor@x-plat.ruНо проблема заключается как раз в том, что количество параметров может меняться. Естественно создавать новый поля для существующих таблиц не приемлемый вариант, да и к тому же потом менять клиент, который будет работать с базой этих объектов тоже нельзя.
Если структура базы (в вашей озвучке ++ атрибуты таблиц) меняются не через день, а редко и очень обоснованно, то почему "создавать новый поля для существующих таблиц не приемлемый вариант"? Клиента менять не придется, если он сразу будет извлекать данные о полях из системных метаданных. Мы так и делаем. Используем системные метаданные и плюс еще завели свои дополнительные. Зато имеем все прелести нормальной структуры БД: производительность, констрейнты, нормальная настройка прав доступа, нормальные запросы, триггеры... Добиться всего этого при структурах типа EAV сложновато, если вообще возможно. EAV все же для совершенно хаотически и часто меняющейся структуры придуман.

Сам клиент не будет извлекать данные - они ему будут web-сервисом передаваться. А свойства будут добавляться совершенно неизвестно когда как и сколько. Мало того после публикации этого поста еще добавилось 1 условие в задании, что конкретному объекту можно добавить свое поле, которого не будет у других.

mir raptor@x-plat.ruСам клиент не будет извлекать данные - они ему будут web-сервисом передаваться. А свойства будут добавляться совершенно неизвестно когда как и сколько. Мало того после публикации этого поста еще добавилось 1 условие в задании, что конкретному объекту можно добавить свое поле, которого не будет у других.Если не сложно, опишите, что за задача этого требует, мне познавательно будет.
Попробуйте все же не полностью на EAV переходить, а делать таблицы с базовым набором полей (даже с запасом), а дополнительные, динамически добавляемые поля уже хранить в отдельной структуре.
SergGol mirЕсли структура базы (в вашей озвучке ++ атрибуты таблиц) меняются не через день, а редко и очень обоснованно, то почему "создавать новый поля для существующих таблиц не приемлемый вариант"? ...Для добавления колонки в любом случае нужен исключительный доступ к таблице. Не во всех случаях это подходит.А что, поля добавляет пользователь в ран-тайме? Тада конечно. Но я говорил о другом случае, когда это -- задача административного характера.

Смогу рассказать о задаче после марта месяца. Пока не могу :)