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 的书籍
书籍 = load_from_server_json('书籍')
good_books = []
对于书中的书{
如果 book["rating"] == 10 (
good_books.append(book)
}
}
这将转换为以下查询
从评分 = 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 family / Homebase，我们可以通过手动优化数据库，一起做DB模型，也就是优化DB模型（作为本体）的规范化。
然而，如果你想自动实现这种事情，我认为，这对 AI 领域来说是一个挑战，在语言翻译（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).