guest_20040621,

Эйфория конечно сильная. :) Особенно по поводу интеграции (потому что задача эта стоит и очень остро для большой кучи предприятий).

Ребята смоделировали определенную задачу для определенного аспекта и остались довольны.

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

Ладно немного доделаю еще тогда видно будет еуда дать крен.

iscrafmСахават Юсифовберешь чужую БД, сгенерируешь свою схему, сгенерируешь все навигационные связи и заливаешь в ЕАВ и получаешь базовый функционал чужой схемы.

как то просто все получается Сахават. Просто не думаю что функционал можно представить в виде модели БД. Она же еще и работать должна, а не просто статически отражать состотояние объектов, как быть с этим?
Что такое "работать"? Что то встроено, что то встроят. Как Искра "работает"?

iscrafmСахават ЮсифовiscrafmСахават Юсифовберешь чужую БД, сгенерируешь свою схему, сгенерируешь все навигационные связи и заливаешь в ЕАВ и получаешь базовый функционал чужой схемы.

как то просто все получается Сахават. Просто не думаю что функционал можно представить в виде модели БД. Она же еще и работать должна, а не просто статически отражать состотояние объектов, как быть с этим?
Что такое "работать"? Что то встроено, что то встроят.
на примере того же планиррования...
Был атрибут ETA. Понадобилось в целях планирования более детально разбить на этапы: ETA Port + ETA Stock. Добавили атрибуты. И что? На этих атрибутах куча логики расчетов завязано, она то откуда таким же легким движением возьмется?

p.s. ETA - Estimated Time Arrived
фигня
вводится новый узел в классификатрое и описывается поведение

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

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

undefinedМСУ в сандалиях,

Да ты, оказывается,сосед!! Я б подошел,еслт коняк не туфтовый. :)
С новым годом, народ!!!!!!!

Что за фигня , блин, автоматом откуда то идет старое сообщение

Вот навигационный граф типа.

undefinedМСУ в сандалиях,

Да ты, оказывается,сосед!! Я б подошел,еслт коняк не туфтовый. :)
С новым годом, народ!!!!!!!

Во МСУ прицепился, блин :(

Вот так будет покарасивше и концептуально правильно.
"Товар" и "Услуга" через агрегирующий тип "Товары и Услуги" (виртуальный, просто узел в классификаторе) связываются с типом "Счет фактура".

Прошло уже 1.5 месяца оказывается.
Теперь реально могу поспорить с любым товарищем о сокрости работы системы построенной на ЕАВ. Скорость Отличная. :)

ASCRUS,

Это все теоретизация. У мня на милллионах записей тормоза такие же как и для обычных таблиц.

И не надо выдмывать что мои клиенты ввожят а чего нет. в МЕС данные генерируюется и учитывается на уровне производственных операций. Временная единица нормирования - секунды.

вощем, все это реально проверено и гут.

SeVa,

Все это делаетеся и на сервере и на клиенте + пейджинг + JIT загрузка данных

_модСахават Юсифоввощем, все это реально проверено и гут.
Чудес не бывает. Поиск объектов по их св-вам возжожен только вумя способами: полный перебор или поиск по индексу. 1-й способ годится для небольших объемов, второй требует полной индексации всех св-в. Поскольку в ЕАВ все св-ва лежат в одной таблице, то и индекс на все один.
Накладные расходы только на многократное объединение таблицы св-в с таблицей самих объектов по ИД - чем больше требуется св-в в запросе тем больше расходы. Такая вот механика.

В ЕАВ все свойства в ОДНОЙ таблице НЕ лежат. Они в разных таблицах и соответственно с разными индексами.
Максимальное количество джойн к таблице объектов в моем случае 8 (типы данных - строка, целое, число, деньги, дата, логическое, образ, объект)

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

Система генерирует для каждой виртуальной таблицы свою хранимку, потому накладные расходы для формирования самого запроса отсутствуют.
Есть и версия с генерацией обычных реляционных таблиц с нисходящими релейшнами( остальные навигационные релейшны формируютс уже в системе).
Так что, при малоизменчивой предметной области (или по мере уменьшения вариабельности) можно переключиться в классический режим поставив галочу..