Megabytedrynnyпропущено...


Концептуально – это байты данных, трактуемые в зависимости от их типа.
В существующих приложениях и сервисах – это текстовое поле, в котором также текстом хранятся числовые значения, в т.ч. datetime.

Т.е. вместо 1млн. чисел вы храните 1 миллион строк(небось еще и максимальной длины)..?
В угоду "универсальности" нормальный такой перерасход пространства.

Я сравнивал, и благодаря нормализации получается почти столько же места база занимает ( здесь можно видеть ), как такая же в оракле, но здесь зато сразу всё проиндексировано.

А у вас есть какой-нибудь вариант названия для этого неоднозначного подхода?

softwarerMegabyteВ угоду "универсальности" нормальный такой перерасход пространства.
СУБД - это универсальное решение. Хорошо отработанное универсальное решение. И вот, очередной квазиархитектор решает использовать это универсальное решение на 0.1% возможностей для того, чтобы создать четыре таблицы и громоздить над ними собственный велосипед. Нетрудно догадаться, что результат получается похожим на самолёт-истребитель, к которому туземец приспособил велосипедную цепь с седлом и пытается на этом плавать.
Живописно как сочинили.

Ну, всякое бывает...
С названием поможете?

SergueidrynnyДля навигации в этом списке построены 3 упорядоченных указателя – индексы: ID, Entity+Attribute, Attribute+Value
При такой организации данных мы можем работать с базой данных любого размера, не имея проблем с производительностью, свойственных системам, построенным на обычном EAV.

Какие ваши доказательства? ) Что значит любого размера?
Это значит, что размер напрямую не влияет на производительность. Конкретнее, в при таком подходе не будет full scan и прочих вещей, присущих EAV, потому что из-за использования индексов система работает с ограниченным набором данных – они находятся быстро.
При каждом удвоении объема данных в индекс добавляется максимум 1 уровень.

SergueiНа каком конкретно объеме данных тестировали?
До 200GB.
Обычно при использовании RAM 1GB в ней занято не больше 100MB.
Вот здесь можно посмотреть графики при работе до 25 пользователей одновременно: habr.com/ru/company/neoflex/blog/451218/#tests

SergueiКакие запросы делали? какого типа атрибуты использовали?
Какие результаты получены?
Атрибуты используются разных типов, включая числовые значения.
Сейчас используется несколько сервисов, построенных на этом решении, результаты в плане быстродействия вполне приличные, а обычное время построения страниц веб-интерфейса находится в пределах 33-150 мс.

SergueiТо же самое,но без EAV что показывает?
Сравнение с обычной базой приведено здесь: habr.com/ru/post/414255/

SergueiНазвание наверное пока еще рановато придумывать...
Если что, задавайте ещё вопросы, а я жду вашего ответа.

vadiminfodrynny[
Пока в голову приходит только REAV – Relational EAV
Это структурная основа RDBMS, но с фиксированным форматом таблиц

Все EAV так как все они RDBMS и потому на структурное основе RDBMS.
Т.е. тогда любую EAV можно было бы назвать REAV.

Кроме того, традиционно термин Relational выглядит много обещающим для МД. Поскольку происходит от понятия Отношения в теории множеств - одной из важнейших теоретико-множественных конструкций. Используется в многих разделах математики.
В частности, в теории реляционных БД. Поэтому как бы от REAV ожидается что-то типа аксиом Амстронга или что-то подобное. Какая-то теория. Ведь это МД.

Поэтому REAV с одной стороны не позволяет отличить от других EAVов, с другой, слишком громкое.

Ок, спасибо. В целом согласен.

Как вариант, можно вообще не использовать аббревиатуру EAV, назвав это типа Quintet data model.
Общался с одним экспертом по БД, и он сразу начал применять термин «пятерки». Пять штук чего-либо называется квинтетом, а у меня все записи содержат 5 полей. Статью одноименную я запилил на хабре об этом.

Что скажете?

Дмитрий Мухdrynny Статью одноименную я запилил на хабре об этом.

Что скажете?
14 декабря 2018 года... удивительно

Ну а что тут?

Мне очень важно ваше мнение.