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（ 'books'）
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.
ああ、あなたは効率的なSQLトランスレータへのトランスレータASTを意味しますか？
ASTについて考え、オブジェクトに対して多くのループを実行し、プロパティを作成およびチェックし、それを効率的なSQLクエリに書き換える方法を考えると、それが難しい場合があります。自動的に機能するシステムが必要です。手続き型クエリを効率的なSQL宣言型クエリに変換します。
Infinityファミリ/ Homebaseに関しては、データベースを手動で最適化し、DBモデルを一緒に操作する、つまりDBモデル（オントロジーとして機能）の正規化を最適化することで、これを行うことができます。
ただし、この種のことを自動的に実現したい場合は、言語変換（ASTからSQL）におけるAIドメインの課題だと思いますが、計算するアルゴリズムが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).