hVostt,

Интересная тема, даже джавовский фреймворк есть axoniq.io , жаль для нас эта тема бесперспективная.

hVosttС выделенным бы не согласился.
Почему? Делается быстро, дешево, сердито и силами половинки землекопа в пределах используемой РСУБД, прикручивать еще одну СУБД, уже понадобится интеграция и полтора землекопа с большим набором скилов и последующая поддержка сложнее.

hVostt,

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

softwarerВы уже второй раз упоминаете это решение. Требуется ли явно упоминать, что конкретно "гибкие поля в OEBS" реализованы совершенно безобразно, настолько, что пожалуй даже EAV предпочтительнее?
Дело имел вскользь, мне идея понравилась, в чем безобразность реализации?

softwarerХотя бы в том, что в таблице просто заранее делаются поля, грубо, FIELD1, FIELD2, FIELD3, FIELD4 - и если тебе понадобился пятый custom-атрибут, сунуть его тупо некуда. Если тебе понадобился custom-атрибут типа даты - храни его как varchar, поскольку мест хранения с типом date не предусмотрено. И так далее в том же духе - я тоже затронул мельком и не знаю всех граблей, это то, что запомнилось из матюков тех, кто этим занимался.
Ограничение по количеству, есть такое, поэтому и думаю что целесообразно использовать для небольшого количества основных аттрибутов, остальной зверинец в EAV, тип значения тоже дает неприятные моменты, но решаемо, в EAV также можно сделать всего одно поле для значения и плеваться потом. Большой плюс гибких полей в том что атрибут в той же таблице что и сущность, не нужны дополнительные соединения с вертикально организованным хранением атрибутов, просто для разных типов одно и то же поле имеет разное по смыслу значение, например для велосипеда поле может содержать тип велосипеда (хардтейл, двухподвес, складной), а для стиральной машины в том же поле будет тип стиральной машины (вертикальная/горизонтальная загрузка), метаданные о типах атрибутов нужно организовывать что для гибких полей что для EAV.

softwarerЭто спорный плюс. Ведь именно он создаёт основные сложности в добавлении новых полей на лету.
В реальности они не добавляются, просто есть запас на "всякий пожарный" случай.

Любое разной степени универсальности решение будет накладывать какие то ограничения и неудобства, серебряной пули нет.

softwarerВ случае OEBS большинство "метаданных о гибких полях" хранилось в голове разработчика.
Да вроде нет там особых вопросов в отчетах, все достается и на самом деле при создании нового типа по моему создается соответствующая вьюха и индексы можно создавать штатными средствами и ключевые поля, т.е. поля по которым будет построен уникальный индекс.

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

softwarerВозможно, при построении отчёта штатными средствами и достаётся. А представьте себе, что хочется использовать какой-нибудь внешний инструмент, ну хотя бы тот же Discoverer?
Было давно и неправда к тому же недолго, но штатным инструментом был Oracle Reports, соответственно отчет представлял из себя вполне обычные запросы, которые нужно было писать ручками, далее отчет запускался в фоновом режиме или по расписанию и результат в виде pdf-ника помещался в какую то папку, ссылка на файл по завершении выполнения появлялась в системе.

softwarerНомер партии
Как бы ты делал сквозные аналитики для приход->сток (внутрискладские операци)->отгрузка, причем для разных клиентов (внедрения продукта) набор аналитик которые они используют может отличаться, т.е. должен быть настраиваемым и сквозным? Понятно что с EAV в такой ситуации лучше сразу застрелиться, но как организовать грамотно?