这样的 nql，大家能接受吗？

改个编写顺序…也没减少字符…也没看出来动态 sql…对我来说用处不大…不如 mybatis hibernate…

看着不错，
复杂嵌套的呢？

复杂的查询大概是这样子写：

query CustomerDetail(customer: CustomerId) {
from customers as c
where c.id == $customer

select {
id: c.id,
name: c.name,

addresses: many {
from addresses as a
where a.customer_id == c.id

select {
id: a.id,
city: a.city,
address: a.address
}
},

orders: many {
from orders as o
where o.customer_id == c.id

select {
id: o.id,
created_at: o.created_at,
total: o.total,

items: many {
from order_items as oi

join products as p
on p.id == oi.product_id

where oi.order_id == o.id

select {
product: {
id: p.id,
name: p.name
},

quantity: oi.quantity,
price: oi.price
}
}
}

order {
o.created_at desc
}

limit 20
}
}
}

老哥还在坚持手搓，是之前写 db 的那个吗

@diudiuu 是，现在在给 https://github.com/sskycn/netbadb 设计新的查询语言。

不兼容 pg,mysql 了，走一条特立独行的路。

@sskycn #5 先关注了，看着写法理解起来还算简单

@sskycn 是直接代替 SQL 么，还是给 SQL 包层壳？

不是代替 SQL ，也不是给 SQL 包层壳。

这是给 NetbaDB 专门设计的一种脚本语言，#1 说的对，还是太复杂了，我还在思考别的方案。

有 ai 之后真的还需要这些吗,把 skill 写好让 ai 写 ,小众语言感觉会愈来愈少人用

有没有兴趣谈谈背后的关系模型建模, 比如 schemaless, 全文搜索/向量搜索 与 关系模型 的结合.
表层的句法在 AI 时代已经没有优化的意义了.

NetbaDB 现在的基本路径是：

Canonical Schema → typed HIR → Typed Relational IR → Planner → Executor → Storage

Heap / LSM 是 authoritative storage ；现在的 Columnar 也是作为 derived projection 存在，而不是另一套数据库模型.

没打算做 schemaless ，而是从用户程序的静态类型定义中生成/推导出来。

强类型和自适应是这个数据库的目标。

老哥很强，但是现在用 AI 已经不关注这些了。