Graph manipulation to queries
Typically with an information system there are two ways of writing systems - one is predominantly through mutating queries and the other is through manipulation of objects in memory such as references between objects. ORMs blur the lines a bit. What if we could silently transform one form to another
This idea is to take code that manipulates objects in memory through dereferences and loops to be automatically rewritten to query based logic.
For loops and while loops can be replaced with queries with conditions on automatically.
Infinity family or homebase is about an ontology that defines objects and their relationships. We also want the operations to be clearly definable and efficient.
+[проект]
Вы имеете в виду что-то вроде того, что объекты - это просто продукты изменяющихся запросов, поэтому нам нужно четко определенное пространство состояний?
// ORM немного размывают линии. Что, если бы мы могли молча трансформировать одну форму в другую
Чтобы разложить объект на запросы, у вас должна быть история мутаций, немного похожая на историю изменений состояния репозитория в git.
Очевидно, что можно разложить каждый объект на запросы, которые его сформировали, предоставив историю для каждого из них. Вы предлагаете иметь истории для каждого типа объектов, правильно ли я это понимаю? Или вы предлагаете нам переместить данные в хранилище данных с контролем версий, что немного похоже на git? Как это будет работать на практике?
Do you mean something along the lines, that objects are just products of mutating queries, so we want a well-defined state space?
// ORMs blur the lines a bit. What if we could silently transform one form to another
To decompose an object into queries, you'd have to have a history of mutations, a bit like git history of repository state changes.
It is obviously possible to decompose each object into queries that formed it by providing a history for each of them. Are you proposing to have histories for each object types, am I understanding it correctly? Or, are you suggesting us moving the data to a versioned data storage, that is a bit like git? How would this work in practice?
По сути, я хочу преобразовать код AST в эффективный запрос, который может выполнять база данных.
Скажем, я искал книги с рейтингом 10/10.
books = load_from_server_json ('книги')
good_books = []
для книги в книгах {
Если книга ["рейтинг"] == 10 (
good_books.append (книга)
}
}
Это будет преобразовано в следующий запрос
Выберите * из книг, в которых рейтинг = 10
Ситуация усложняется, когда есть граф объектов, где есть манипуляции с несколькими полями. Как вы и сказали, вам нужно, чтобы код отслеживал мутации, чтобы решить, как сгенерировать эффективный запрос, включающий соединения.
Essentially I want to transform code AST into an efficient query that a database can execute.
Say I was looking for books with a rating of 10/10
books = load_from_server_json('books')
good_books = []
for book in books {
If book["rating"] == 10 (
good_books.append(book)
}
}
This would be transformed into the following query
Select * from books where rating = 10
It gets more complicated when there is a graph of objects where there is manipulations to multiple fields. Like you say, you would have to have the code trace the mutations to work out how to generate an efficient query that incorporated joins.
Будет ли это изобретение чем-то вроде ORM, которое поддерживает создание графа мутации данных из коробки?
Would this invention be a kind of "ORM", that supports making data mutation graph out of the box?
Это была бы форма ORM. ORM отслеживают загрязненность отдельных записей, а не групповых записей.
Цель состоит в том, чтобы найти более эффективные представления ручного кода и преобразовать его в эффективные запросы.
Проблема с циклами for (и ORM) заключается в том, что вам нужно, чтобы данные находились в памяти. База данных лучше выполняет подкачку записей в память, чем наивно написанный код, который загружает все сразу.
It would be a form of ORM. ORMs track dirtiness of individual records not bulk records.
The goal is to find more efficient representations of manual code and convert it to efficient queries.
The problem with for loops (and ORMs) is that you require the data be in memory. The database is better at paging in records into memory than naively written code that loads it all at once.
Вы имеете в виду транслятор AST в эффективный транслятор SQL?
Когда вы думаете об AST и о том, что он может выполнять множество циклов над объектами, создавать и проверять свойства, а также о том, как переписать это в эффективный SQL-запрос, иногда это может быть проблемой, и вам нужна система, которая автоматически преобразовать ваш процедурный запрос в эффективный декларативный запрос SQL.
Когда дело доходит до семейства Infinity / Homebase, мы могли бы сделать это, вручную оптимизировав базу данных и вместе работая над моделью БД, другими словами, оптимизируя нормализацию модели БД (которая служит онтологией).
Однако, если вы хотите достичь такого рода вещей автоматически, я думаю, это проблема для области ИИ, в переводе языка (AST на SQL), хотя, возможно, это была бы более простая версия перевода, потому что алгоритмы для вычисления функции данных, необходимые для выполнения SQL-запроса, уже были бы встроены в AST, просто нужно было бы найти хорошие подзапросы для SQL («язык структурированных запросов» - я думаю, что само имя SQL подразумевает, что мы можем делать структурированные подзапросы -запросы для получения окончательного результата запроса).
Oh, you mean translator AST to efficient SQL translator?
When you think about AST, and that it could be doing many loops over objects, creating and checking properties, and how to rewrite that into an efficient SQL query, it can sometimes be a challenge, and you'd like a system that would automatically translate your procedural query into efficient SQL declarative query.
When it comes to Infinity family / Homebase, we could do this by manually optimizing the database, and working on the DB model together, in other words, optimizing the normalization of DB model (that serves as ontology).
However, if you want to achieve this kind of thing automatically, I think, it's a challenge for AI domain, in language translation (AST to SQL), though, it would perhaps be a simpler version of translation, because the algorithms to compute the data features required to do an SQL query would be already embedded in the AST, one would just need to find good sub-queries for SQL ("structured query language" -- I think the SQL name itself implies, that we can do structured sub-queries to arrive at the final result of query).