数据库管理-第205期 换个角度看23ai（20240617）

数据库管理-第205期 换个角度看23ai（20240617）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，HaloDB外聘技术顾问、OceanBase观察团成员，青学会（青年数据库学习互助会）外部顾问
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

本来耽搁了几期，想给优先级事务做个实战收尾，结果FREE版不支持这个功能（其实测试了一下，特定版也没有对应的参数，应该是23ai新加的功能）：

只能作罢，等OP版，应该也快了。起了个头总想着写完，这一期换个角度看看Oracle Database 23ai的关于应用开发的一些新功能。

1 规范应用开发

其实稍微认真看看JSON关系二元性视图和属性图，实现二者功能的方式本质上是十分类似的，其实就是通过创建view或graph来将关系数据表映射成JSON或图。但是说真的，想要短时间去颠覆传统的直接使用MongoDB存储JSON和Neo4J存储图数据还是很难的。但是换一个角度，无论是JSON关系二元性视图还是属性图，都需要将底层的关系数据表设计的很好，需要按照范式要求设计并指定好主外键。
这里就先不说范式设计了，网上文档一抓一大把，好处劣势都讲的很清楚，但是在OLTP系统中我认为是有用的。毕竟很多时候数据库出现问题大多数是SQL写的不好，而良好的表逻辑设计可以极大避免烂SQL出现的概率，而良好的表逻辑设计也可以更好地支撑应用的功能迭代、变更与增加。在Oracle Database 23ai上还能使用上更多的融合数据库功能。

2 融合

很多人认为，融合数据库和多模数据库似乎是很相近的概念，但在我看来，还是有很多不一样。很多多模数据库仅仅是将一些其他数据模态作为一种新增的数据类型只能使用SQL进行操作；也有些数据库是将其他模态数据库操作方式直接加入数据库中，但大多无法与关系表联查。
而Oracle融合数据库，除了将其他一些数据模态引入为新的数据类型以外，也用了关系表映射的方式实现了JSON并可通过MongoDB API进行操作；引入可以使用KafKa API操作的TxEventQ，强力支持微服务架构；简单SQL可完成查询和完整DML操作的Vector数据类型；无需修改数据操作方式的全功能True Cache…不仅支持SQL操作多模数据，也支持传统方式去操作，有些还做到了两种方式均可操作，这样我才是我认为的融合数据库。

总结

今天内容写的晕晕乎乎的，换了个角度看Oracle Database 23ai。
老规矩，不知道写了些啥。