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).