Комментарий к «Экспертная система для когнитивных моделей»от serj_aleks в metamodeling

Совсем коротко:
поскольку я упёрся рогами в экосистему Erlang, то естественным решением будет запилить для ErlangVM специальный диспетчер именованных объектов (функций, ячеек, каналов etc.)/

Я тут на днях замечал, что Erlang-система по своей сути есть огромная БД хранимок-триггеров с механизмом их поиска/запуска по методу сопоставления с образцом.
Соотв, само напрашивается расширить семантику сопоставления с образцом, добавив специальные операции типа генетических (напр вызова функции-генератора по функц близости к образцу, мутации и т.д.).
Вот примерно об этом я и думаю, что думаю.

***** ***** ***** ***** *****
Популярные usecase графовых БД (всякие там Neo4j и проч) чаще всего сводятся либо к поиску аттрактора/первоисточника («центральной звезды»), либо к переносу операций-со-схемами-данных в набор-данных (типовое: категории товаров с шаблонами их свойств/параметров, когда вместо создания отдельной таблицы для каждой категории каждый товар обвязывается дочерними узлами в GhaphDB; когда-то так делали в упомянутой мной db_vista).

В последнем usecase графовые соревнуются с документными (та же Mongo), причём лично я в подавляющем большинстве "вокруг-продажных" бизнес-приложений на стороне документных (некоторые извращенцы даже конфиги приложений в Монге хранят).

/* В промышленных RDBMS стоимость операций со схемами (CREATE/MODIFY TABLE) жутко высокая, а использование в кортежах эксплицитной типизации в виде пар/туплов «тип:значение», и соотв сложных каскадных selest/join сильно грузит движки БД (хотя и работает).
Происходит это потому что на каждый запрос производится широкая/глубокая выборка данных из экстентов с соотв Big_IO, и послед сильное отсеивание); в графовых/документных весь объект [переменной структуры] хранится компактно.

NB: В типа-непромышленной FoxPro была технология Rushmore — если поле таблицы имело индекс, то данные брались из индекса; при известной ловкости можно было брать данные только из индексов, без обращения к таблицам; т.о. "точечная" (не-массовая, не-агрегатная) работа с реляционкой была по профилю исполнения (обращений к дисковым структурам) больше похожа на работу с графом */

Посмотреть обсуждение, содержащее этот комментарий

Error

Anonymous comments are disabled in this journal

default userpic

Your reply will be screened

Your IP address will be recorded