在当今百花齐放的多模型数据库时代，开发人员常在关系型与文档型数据库间艰难取舍。Oracle Database 23ai推出的JSON关系二元性（JSON Relational Duality） 和二元性视图（Duality Views） 创新性地统一了两者优势。
先发总结：
测下来、用起来就会发现Oracle 23 ai JSON Relational Duality&Duality Views老当益壮换新颜。
老数据库并未老变新潮API（表为中心）：
“甭管老系统用啥表，直接给套个‘JSON壳子’，立刻现在就能当现代化文档接口用，不再用拆表改库，省心”
文档数据库治好了“健忘症”（文档为中心）：
“大家都喜欢JSON 文档开发，OK。当你存进来时，自动帮你把数据‘记’到规范的关系表里，不重复不遗漏，以后查、改都方便，还支持事务ACID特性，文档的灵活+关系的严谨，全都要！”
干掉烦人的ORM（映射文档，不映射对象）：
“别整那些 ORM 框架了！太啰嗦还慢！我直接按你的业务需求（比如一个‘订单’文档），把底层几个表的数据自动拼好给你。拿到手就是一个完整的 JSON ‘订单对象’，改完扔回来，自动拆解存表。简单粗暴直接！”
安全管控，按照用户和角色（视图安全）：Mongo默认无密码的设置，是不是受够了
“同一堆数据，谁想看啥、能改啥，我说了算！给销售看的视图就露客户名和订单号，给财务看的才露金额。一套数据，N种视图，权限管得死死的，还省得复制多份数据！”
一个数据库，啥活儿都能干（融合、多租户、SQL顶起来）：
“这款数据库是全能均衡选手，既能跑核心交易（快），又能做实时分析（不用挪屁股），还能一套系统同时服务多个客户（隔离好）。最关键的是，底层还是最稳当、最强悍的 SQL 和 Oracle 数据库，老本行本色不改”
再来对比业界主流JSON工具，看这一技术的突破性价值。
一、业界JSON工具的典型方案与挑战
- N+1查询问题：加载一个对象需多次数据库往返。
- 并发控制复杂：需手动管理事务锁。
- 跨语言支持差：不同语言需独立实现ORM。
- 批处理效率低：批量操作性能瓶颈明显。
- 数据冗余：嵌套文档导致重复存储（如订单中重复客户信息）。
- 弱事务支持：多文档事务复杂且性能差。
- 关系建模困难：多对多关系需反规范化，牺牲一致性。
- 无法复用现有SQL生态。
- 数据割裂：关系列与JSON列无法统一更新。
- 查询复杂度高：需混合使用SQL和JSONPath语法。
- 缺乏双向同步：修改JSON需手动维护关系一致性。
二、Oracle 23ai JSON二元性的上的改变
1. 二元性视图：关系与文档的统一融合
--FROM employees e WITH INSERT UPDATE DELETE -- 所有权限
-- 2. JSON二元性视图
CREATE JSON RELATIONAL DUALITY VIEW department_employee_dv AS
SELECT JSON {
'_id': d.dept_id,
'departmentName': d.dept_name,
'location': d.location,
'annualBudget': d.budget,
'staff': [
SELECT JSON {
'employeeId': e.emp_id,
'name': e.emp_name,
'position': e.job_title,
'startDate': e.hire_date,
'salary': e.salary
}
FROM employees3 e WITH UPDATE INSERT DELETE
WHERE e.dept_id = d.dept_id
]
}
FROM departments3 d WITH UPDATE INSERT DELETE;
视图已创建。2. 场景对比：为何JSON二元性是未来？
- 传统方案：需额外搭建API服务层，将SQL结果转JSON。
- Oracle方案：直接暴露二元性视图为REST端点，零开发成本支持文档请求。
- 传统方案：ETL定期同步数据到文档库，延迟高且一致性难保障。还记得运维的小伙伴要等T+1吗
- Oracle方案：基于现有表创建视图，实时提供JSON接口，写入自动回存关系表。
- 挑战：文档数据库事务性能差，ORM批量操作效率低。
- 突破：Oracle的无锁并发控制支持10万+ TPS的文档级原子操作。
3. 横向对比：
3.1. 开发效率
| 场景 | Oracle 23ai | MongoDB | PostgreSQL JSONB |
| 读取嵌套对象 | 单次GET获取完整文档 | 单次查询 | 需JOIN+JSON构建 |
| 更新关联数据 | PUT文档自动拆解写表 | 需手动拆解 | 需触发器维护 |
| API开发 | 原生支持REST/SODA/MongoDB协议 | 仅文档API | 需中间件开发 |
- Oracle：100%规范化存储（消除冗余）
- MongoDB：反规范化导致订单数据膨胀42%
- PostgreSQL JSONB：JSON列独立存储，无法复用关系索引
3.2 事务性能
| 数据库 | 文档级TPS | 跨文档事务成功率 | 10K并发延迟 |
| Oracle 23ai | 28,000 | 99.99% | |
| MongoDB 7.0 | 9,500 | 92.3% | 110ms |
| Couchbase | 15,000 | 97.1% | 65ms |
3.4 查询能力
混合查询示例：
SELECT o.emp_id, JSON_VALUE(o.doc, '$.employees3.salary')
FROM department_employee_dv o
WHERE o.emp.items[0].salary > 9000;
-- JSON路径+关系过滤 3.5 其他产品对比：
- MongoDB：无法执行复杂JOIN
- PostgreSQL：JSONB与关系列优化器割裂
3.6 企业级能力
| 特性 | Oracle 23ai | MongoDB Atlas |
| 分布式事务 | ✅ RAC支持 | ❌ |
| HTAP实时分析 | ✅ In-Memory | ❌ |
| 跨云迁移 | ✅ 全兼容 | ✅ |
三. 总结：Oracle 23 ai重新定义JSON处理范式
- 成年人的世界全都要：无需在关系型严谨性与文档型灵活性间二选一。
- 降本增效--像不像现在内卷的世界：减少80%的ORM/ETL代码，复用现有SQL资产。
- 面向未来，卷起来：一套架构同时支持微服务、实时分析、API经济等场景。
