авторОчень похоже на EAV, только еще добавлено время.
...
Система обрабатывает примерно 3000 показателей по 22000 объектов. И я затрудняюсь представить себе непротиворечивую работу подобной системы на основе другой модели данных. Ваще не понял... Что разумеется под "непротиворечивой работой"?
автор 1.В настоящее время подобная модель реализована в подсистеме OIS УСОИ – Универсальная Система Обработки Информации программного комплекса OilInfoSystem
...
3.Теперь о производительности. Производительность системы УСОИ оставляет желать лучшего. Собственно, это тот момент, который подтолкнул меня к поиску и разработке альтернативного варианта.
Почему я решил, что это мне удастся? Ведь в УСОИ используется флагман СУБД – Oracle, да и разработчики системы люди незаурядные, не один год над системой работали. Ну а чего вы хотите от EAV? На приличных объемах эта структура очень тормозная, в какую СУБД ее не засунь. А тут еще и временную составляющую прилепили...

Ну и собственно, в чем заключатеся ориентированность на показатели?

DirksDRbaracsВаще не понял... Что разумеется под "непротиворечивой работой"? Непротиворечивая - это когда поменял исходные данные, открыл отчет - а там уже все пересчитано. Открыл другой - там тоже пересчитано.
Противоречивая - это когда поменял исходные данные, открыл отчет - а там производные данные старые, потому что пересчет
производных данных выполняется по расписанию в 2:15 программой расчета.
Или когда в двух отчетах расчетные данные разные, потому, что в одном алгоритм поменяли, а в другом еще нет. А как это связано с моделью?
DirksDRbaracsНу а чего вы хотите от EAV? На приличных объемах эта структура очень тормозная, в какую СУБД ее не засунь. Т.е. разница в производительности на порядок Вас не вдохновляет? Разница чего с чем?
DirksDRbaracsНу и собственно, в чем заключатеся ориентированность на показатели? Наверное, можно назвать значение определенного атрибута определенного объекта в определенный момент времени как-то иначе.
Например, тэгом, но мне "показатель" кажется более подходящим. Я не про названия, а про суть.

Dimitry SibiryakovbaracsНу а чего вы хотите от EAV?
Лично я хотел бы видеть пример тормозящего запроса и его план. Грамотно. Поскольку я - "разработчик с табличным шаблоном", EAV не люблю и имел дело с такими таблицами - в сотню строк максимум, постольку примеров тормозящих запросов к ним у меня нет.
Но есть старое исследование: Сравнительный анализ некоторых методов O - R-преобразования .
автор В качестве примера реализации анализируемых подходов рассмотрим справочную информационную систему «Электронный каталог» книжного магазина.
В основу положена база данных реального интернет-магазина. Полное описание структуры представлено в виде диаграммы классов предметной области (рис. 1).
База данных содержит информацию о 101 087 экземплярах товара, распределенных по 588 разделам, в том числе – 84 287 книг, 6 793 периодических изданий, 10 007 наименований кассет. База данных также содержит информацию о 5 243 издательствах и 42 857 авторах книг.

Т а б л и ц а 8
Время выполнения операций и объемы баз данных
ПараметрМодель ROT Модель ROT с наследованиемМодель ТенцераМодифицированная модель ТенцераОткрытие всех таблиц базы данных с 5.72–5.74 4.71–4.72 14.01–15.11 14.04–15.16Выборка всех данных по одной Книге без определения типа с 6.57–6.63 15.10–16.02 31.29–31.36 7.83–8.93Выборка всех данных по одной Книге с определением типа с 6.29–6.33 14.18–14.24 30.05–30.82 8.56–10.17Выборка всех данных по одной Кассете без определения типа с 6.43–6.49 15.12–15.14 15.67–16.46 8.71–10.05Выборка всех данных по одной Кассете с определением типа с 0.53 1.06–1.08 4.11–5.29 4.80–5.92Выборка всех данных по всем товарам с 60.12–91.90 206.47–236.32 97.81–135.25 94.83–113.11Вычисление суммы товаров в корзине с 8.61–8.84 8.45–9.35 12.08–13.06 13.50–14.86Добавление новой Книги с 0.03–0.05 0.04–0.13 0.14–0.55 0.17–0.57Изменение данных по одной Книге с 1.31–1.35 2.50–2.61 3.12–8.81 3.62–9.25Объем базы данных МБ 39.5 43.7 49.7 56.6 Dimitry SibiryakovEAV сама по себе, как и любая другая модель данных, вещь пассивная и тормозить не может. Согласен, сформулировал некорректно. Тормозят выборки размазанных по длинной колбасе данных. Т.е. чтобы вытянуть значения атрибутов какой-то одной сущности, с высокой вероятностью, надо облазить всю таблицу. Dimitry SibiryakovНо её своеобразный характер часто вступает в конфликт с табличным шаблоном некоторых разработчиков, которые после этого пытаются совершенно дикими запросами уложить данные в привычное им прокрустово ложе. Красиво, но непонятно.

DirksDRbaracsпропущено...
Разница чего с чем?
реляционного EAV и "key-value" EAV Гм-м... Что-то я пропустил. Сходил по ссылке еще раз: авторОсобенностью СУБД Cache является несколько вариантов доступа к данным:
- Объектный (COS – Cache Object Script)
- SQL
- Direct Access.
Если первые два варианта предоставляют современные высокоуровневые языки программирования, обеспечивающие скорость разработки, то третий вариант – это высокоскоростной «key-value» доступ к данным , обеспечивающий максимальную производительность. Следует ли это понимать так, что ключевым преимуществом вашей модели, является ее реализация на Cache?

DirksDRbaracsСледует ли это понимать так, что ключевым преимуществом вашей модели, является ее реализация на Cache? Вы же сами писали авторНу а чего вы хотите от EAV? На приличных объемах эта структура очень тормозная, в какую СУБД ее не засунь. Имелись ввиду реляционные. DirksDR1.EAV может прилично работать на приличных объемах. Почему же незаурядным разработчикам, на флагмане СУБД, за несколько лет не удалось этого добиться (по вашим словам)?
DirksDR2.Если "засунуть" EAV в Cache, можно повысить скорость в несколько раз за счет "key-value".
Не назвал бы это ключевым преимуществом, скорее "одним из". Кот Матроскинмы же обсуждаем не частный случай, а "систему для хранения параметров" вообще. А так, топик надо было создавать в "Сравнении СУБД".

Dimitry Sibiryakov baracsесть старое исследование Читать которое становится смешно уже после "в качестве хранилища выбрана база данных
формата MS Access 2000". Запросов - не приведено. Их планов, естественно, тоже. Ну, ткните в сравнение на промышленной СУБД с планами. Dimitry Sibiryakov baracsТормозят выборки размазанных по длинной колбасе данных. Т.е. чтобы вытянуть
значения атрибутов какой-то одной сущности, с высокой вероятностью, надо облазить всю
таблицу. Построить индекс на поле связи "сущность-атрибут" мешает что-то?.. Нет, но высока вероятность IndexScan-ов вместо Seek-ов. А т.к. таблица узкая, IndexScan не сильно эффективнее TableScan-а.