Спасибо за полезную ссылку, есть на что посмотреть и подумать.
Ваша штука не взлетит
.
Немного голословно и непонятно, куда не взлетит.
Тут важно понимать цель — наша штука рассчитана на конкретные потребности, и, при всем разнообразии доступных компонентов, в нашем случае исследование buy vs build не имеет готового buy решения.
Ядро выложим в git как дотестируем стабильную версию.
Посмотреть как это работает, результаты некоторых тестов, самому помучить и потестить — могу дать ссылку.
Для того, чтобы было понятнее и другим, и вам самим, объясните, чем этот подход отличается от достаточно широко (и многим — печально) известных триплов ака EAV.
EAV — это не подход, а структура. Можно сказать, что это подход к представлению данных, и не более.
А здесь описан подход к построению информационной системы, где данные (в т.ч. алгоритмы) хранятся в предельно простом и унифицированном формате.
Зачем вы расширили этот подход, какой выигрыш и где можно получить? «Зачем?» — вообще главный и не-отвеченный вопрос, возникающий по прочтении поста.
Выигрыш может быть в скорости разработки, во всяком случае мы стали быстрее разрабатывать приложения, применяя этот подход. Поскольку система хранения унифицирована, к ней можно прикрутить различные варианты интерфейса, который скроет много тривиальной, черновой работы, устранит часть связанных с этим рисков и снизит порог вхождения для разработчика.
Избыточность, причём ссылка по дереву явно будет работать только в очень узком применении, которое в начале разработки предполагалось основным. По мере строительства продукта обычно оказывается, правда, что это не так :-)
Ссылки между квинтетами работают при каждом обращении к данным — это связующая информация и другой никакой нет (нет схем, таблиц, полей). Избыточность присутствует, да, как плата за унификацию и удобство работы со структурой и данными.
индексы не являются обеспечителями надёжности, только скорости. На то они и индексы, что их можно перестраивать независимо от операций с собственно моделью. Альтернатива — обязательные индексы, и тогда у вас не квинтлеты, а уже нагромождение. Чего я, собственно, и ожидал.
Пользователи не очень любят перестраивать индексы и платить за это тоже не всегда желают. Избыточность, как я упомянул выше, это достаточно дешевая альтернатива.
И вообще непонятно, если уж на то пошло, зачем Вы перегрузили триплы лишней информацией, если, по сути, строите то же самое. Могли бы взять готовое, а не бегать по граблям. Впрочем, и в готовом виде триплы — бяка.
Я бы не стал привязываться к триплам, и по сути я строю нечто иное и с иной целью.
CIMы (Common Information Model) существуют в изрядном множестве для разных областей.
Мы не изобретали новую CIM, а реорганизовали представление данных, чтобы с ними было проще и нагляднее работать, не изменяя подход к хранению данных в принципе. Это работает до модели, на уровне квантов данных, без привязки к конкретной области.
И они показывают, что реальность не может опираться на такие простенькие структуры, как представлено в посте. Ну, разве что очень простые реальности…
Для этого и была написана статья — описать подход, применимый к структуре любой сложности, какая может встретиться в современных приложениях.
Поскольку у вас наверняка есть уверенность, что это не сработает сомнения по каким-то конкретным моментам, я готов ответить на вопросы, рассказать на конкретных примерах, как именно это сработает, и показать в реальности.
Хотя, вообще-то, в моделях данных по крайней мере половина объёма — вообще неидентифицируемые объекты (то есть не имеющие выделенного идентификатора).
Да, это именно так. Они неидентифицируемы, что создает определенные проблемы, когда пользователи хотят их анализировать.
Современный пользователь хочет всего и сразу, и его требования часто меняются быстрее, чем мы успеваем обновить нашу систему: изменить типы реквизитов, размерность, индексировать некоторые поля, используемые для поиска только здесь и сейчас.
Мы часто решаем эти проблемы и придумали способ их уменьшить. Это работает, и принято решение расти.
Вы правильно заметили про движок — здесь описан подход к его разработке.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.
В этой статье описана реализация, там же есть оценка производительности.
.
Немного голословно и непонятно, куда не взлетит.
Тут важно понимать цель — наша штука рассчитана на конкретные потребности, и, при всем разнообразии доступных компонентов, в нашем случае исследование buy vs build не имеет готового buy решения.
Посмотреть как это работает, результаты некоторых тестов, самому помучить и потестить — могу дать ссылку.
EAV — это не подход, а структура. Можно сказать, что это подход к представлению данных, и не более.
А здесь описан подход к построению информационной системы, где данные (в т.ч. алгоритмы) хранятся в предельно простом и унифицированном формате.
Выигрыш может быть в скорости разработки, во всяком случае мы стали быстрее разрабатывать приложения, применяя этот подход. Поскольку система хранения унифицирована, к ней можно прикрутить различные варианты интерфейса, который скроет много тривиальной, черновой работы, устранит часть связанных с этим рисков и снизит порог вхождения для разработчика.
Ссылки между квинтетами работают при каждом обращении к данным — это связующая информация и другой никакой нет (нет схем, таблиц, полей). Избыточность присутствует, да, как плата за унификацию и удобство работы со структурой и данными.
Пользователи не очень любят перестраивать индексы и платить за это тоже не всегда желают. Избыточность, как я упомянул выше, это достаточно дешевая альтернатива.
Я бы не стал привязываться к триплам, и по сути я строю нечто иное и с иной целью.
Мы не изобретали новую CIM, а реорганизовали представление данных, чтобы с ними было проще и нагляднее работать, не изменяя подход к хранению данных в принципе. Это работает до модели, на уровне квантов данных, без привязки к конкретной области.
Для этого и была написана статья — описать подход, применимый к структуре любой сложности, какая может встретиться в современных приложениях.
Поскольку у вас наверняка есть
уверенность, что это не сработаетсомнения по каким-то конкретным моментам, я готов ответить на вопросы, рассказать на конкретных примерах, как именно это сработает, и показать в реальности.Связь может быть сколько угодно сложной, и квинтет позволяет её проследить, указывая следующее звено этой связи и доводя в итоге до мамы и папы.
Вы можете называть это EAV. Только к нему ещё добавлены идентификатор и порядок.
Не уверен, что понял вас. Вы сами сказали «половина объёма — вообще неидентифицируемы».
Ссылки двунаправленные — оба упоминания ID проиндексированы, значит их можно сопоставить в любую сторону, равно как и собрать все связи с заданным ID.
Сами квинтеты хранятся не деревом, а списком. Деревья же используются для быстрого нахождения значения в списке.
Да, это именно так. Они неидентифицируемы, что создает определенные проблемы, когда пользователи хотят их анализировать.
Современный пользователь хочет всего и сразу, и его требования часто меняются быстрее, чем мы успеваем обновить нашу систему: изменить типы реквизитов, размерность, индексировать некоторые поля, используемые для поиска только здесь и сейчас.
Мы часто решаем эти проблемы и придумали способ их уменьшить. Это работает, и принято решение расти.
А байты мы посчитаем в одной из следующих статей и сравним с существующими решениями.
Для создания платформы нужно развивать инфраструктуру и нарабатывать практики, а это уже следующий этап.
Принципиально, на мой субъективный взгляд, самое важное улучшение — это возможность начать всё с чистого листа, постепенно усложняя прикладную часть и избегая известных ошибок.
Соответственно, развитие сейчас заключается в создании энтузиастами нужных им примитивов, решающих очень простые задачи, коих, если присмотреться очень много. По итогам этих работ появляются артефакты, а сами энтузиасты решают для себя насколько им это нравится или не нравится. Сама концепция при этом получает практическое подтверждение жизнеспособности и позволяет запланировать дальнейшие шаги, решая более сложные задачи.