OceanBase 数据库（后简称 OB ）最大的用户群体还是开发者，为了降低开发者使用 OB 的技术门槛并提升使用体验，OB 在很早就推出了自己的数据库客户端工具 ODC。在早期这么做的另外一个原因是市面上传统的数据库客户端工具也并不懂 OB 。
ODC 全称 OceanBase Developer Center，面向开发者的。ODC 在客户群体里口碑很好，作为 OB 数据库客户端只是它最基础的功能。ODC 的亮点远不止于此。
智能的数据库开发客户端
数据库开发客户端的基础功能包括数据库存储对象设计(如表、视图）、数据库编程对象设计（触发器、函数、存储过程、包）、数据库作业设计等。传统数据库客户端做得最好的是微软的 SQL Server Management Studio 。ORACLE 数据库客户端做得最好的是 SQL Navicate 和 PL/SQL Developer。后者的 PL/SQL 调试能力更是深受开发喜欢。这些产品工具的体验都比较好，其中一个原因是都是 Windows 程序。 国产数据库的客户端都倾向以 Web 窗口形式运行，这样用户就不用安装客户端程序。Web 程序有自身的特点，性能依赖浏览器的功能。ODC 也是一个 Web 程序，虽然也有客户端版本，但本质上是将 Web 嵌入到客户端的窗口里。开发 Web 程序是互联网公司的强项。
ODC 降低 OB 开发技术门槛的关键，是一序列技术：
支持图形化创建表。建表的相关参数会在图形化页面上有反馈，有些是必填参数会设置默认值并提示必选
OB 的一些特殊功能或高级功能通过图形化页面提供。
如虚拟列的用法。
图形化设计会转换为 SQL
点击“提交并确认SQL”，会转化成 SQL 。这也是学习 OB SQL 的一个方法。
执行 SQL 时会自动检查是否遵守开发规范
有些客户用了 OB 后会希望 OB 团队给一些开发规范和最佳实践。殊不知这些规范已经被融入到 ODC 中了。
ODC 里维护了大量这种开发规范，根据规范的重要性分为“无需改进”、“需要审批”和“必须改进”三个级别。此外还根据开发使用场景选择不同的安全规范。通常来说生产环境安全规范限制比较严格，开发环境比较宽松。
以上这些功能点虽然简单很好理解，但能节省开发时间，实际上也可能就是节省 DBA 的时间。每个开发节省 5 分钟，10 个开发就节省 50 分钟。
ODC 的公有云上的形态（SQL 客户端）还引入了大模型技术，支持文本转 SQL 技术。这个能方便一些非技术专业人员。对于开发者，会写 SQL 还是最基本的技能要求。
灵活的审批流程
ODC 开发规范能规定的只是一些 SQL 层面通用的用法，并不能防止业务上的设计问题。传统数据库的问题之一就是生产环境混乱。如表命名混乱、备份表混乱、表结构设计类型不当、索引创建不当等。这里面固然有一部分原因是没有 DBA，仍有一部分原因是账户使用不当。很多人都有建表建索引的账户。随意建表、改表结构、加索引、订正数据等等。虽然金融机构针对数据库变更也有规范，但那个的重点只是流程合规，对于变更的内容，审批人不一定会去分析，因为那些审批系统都是独立于数据库之外的。除非审批人愿意花费精力去分析数据库。
ODC 里有审批流程设计，针对不同类型的变更类型可以根据风险自定义不同的审批流程。风险很低的建表可以自动审批，表结构变更、索引变更需要 DBA 审批。DBA 审批的时候可以从系统中自动获取相应的表结构和索引信息，甚至可以查看数据特点等以评估这个变更的风险。
集中的数据源管理
企业里数据库实例很多，每个实例里又有多个 Schemas 或 Databases ，数据库开发都是在具体的 Schema 或 Database 下。这个导致 DBA 要管理很多数据库连接信息。传统企业里往往有很多数据库账户分散在很多开发手上，时间久了都没人说得清楚到底哪些人有数据库操作权限。如果把这些数据源在服务端集中管理，并通过平台控制能访问数据库的人员，那就没有这个安全风险了。所以 ODC 也倾向于用 Web 集中管理数据源。在 ODC 里一个数据源对应一个租户，即使租户下有多个数据库，也都属于一个数据源。每个数据源只需要一个高权限账户即可（用于 ODC 跟数据源之间的连接）。
用户和角色
ODC 跟数据源之间只用一个高权限账户建立连接，用户不直接访问数据库，而是通过 ODC 简介访问数据库。ODC 为每个用户建立一个独立的用户账户并通过用户页面集中管理。ODC 可以为每个用户分配对应的权限，对于有同类权限需求的用户可以单独创建一个角色，给角色分配权限，然后用户加入到角色里即可。ODC 里的用户不是数据库里的账户，所以大大降低了数据库的风险。不过这个设计不同客户有不同的想法。有的客户就觉得这个要创建很多用户反而更麻烦，他们还更倾向于直接给对应的业务应用一个账户，然后就放手不管了。所以，ODC 这个用户和角色功能的使用并不是单纯的技术问题，而是一个企业管理的问题。权限的收敛管控是控制数据库风险和性能的重要手段。这是一个权利和责任的问题。ODC 也可以对接企业内部的账户登录系统，免去创建用户这一步。
ODC 角色的权限分为两类：
资源管理权限
资源包括数据源、项目、角色和用户等。少数管理人员需要创建用户、角色和项目，大部分开发者只需要数据源的编辑或查看权限
系统操作权限
系统操作权限主要是定义 ODC 系统里功能的权限。
大部分权限都属于管理员的管理范畴，普通人不需要。个人空间是一个比较特殊的功能。
个人空间和团队空间
ODC 支持个人空间和团队空间两种模式。个人空间对应于早期 ODC 版本的用法。每个用户申请对应数据源的读和写权限。申请后，个人空间里的操作就不需要审批了。这是为了部分人员不想受流程审批困扰而保留的功能。一般仅限于 DBA 或开发负责人用。 团队空间适合项目开发，集中管理大批用户的数据库访问权限、流程审批等。
数据脱敏
ODC 将所有数据源访问权限收敛到平台里后，就衍生出一些实用的功能，比如说数据脱敏需求。ODC 可以定义哪些字段是敏感数据，对这些数据的查询、修改都需要严格的流程审批。这样可以控制业务敏感数据泄露。
定时任务
这是 ODC 的并不广为人知的一个实用功能。对于分区表，OB 目前并没有自动创建分区、删除分区的功能。虽然 OB 支持 JOB ，可以在 JOB 里写存储过程做这个，但这个透明度就不是很高，需要读写数据库才能看到相关作业。
对于分区大表，ODC 可以创建定时任务定期创建分区、定期删除历史分区。也可以创建任务定期归档历史数据到其他表然后删除当前数据。
以分区表维护计划任务为例。
建一个分区表
定时创建分区和删除历史分区
在一个定时任务里创建新分区和删除历史分区。
设置创建新分区时的分区策略。RANGE 分区名的命名尽量带上时间的特征。这里面初次使用时会有点难度。
定时任务建好后，后续会自动以工单形式运行。
可以查看一个工单执行的详细内容，确认工单设计符合预期。
数据库开发生态
OB 有两种租户兼容模式：MySQL 和 ORACLE 。基本上传统的 MySQL 数据库客户端工具连接 OB 的 MySQL 租户是可以使用的，但是 ORACLE 租户就不能连接了。开源的 DBeaver 是通用的数据库客户端工具，可以使用 JDBC 连接 OB 的 MySQL 和 ORACLE 租户。但是它的功能也就仅限于常用的客户端功能（数据库对象开发设计、SQL编写、数据导出等等）。
ODC 依然是连接 OB 的 ORACLE 租户最好的客户端工具。尽管 ORACLE 租户是 OB 企业版才有的功能，ODC 确是开源的，并且版本迭代发布很快。当然迭代太快的负面影响就是质量可能下降。ODC 的版本总会有一些使用的小问题，一旦发现了就等后续版本修复。
ODC 的功能始终是围绕 OB 的使用需求来的。由于 OB 的一个使用场景是将传统关系数据库或分布式数据库同步到 OB ，以及 OB 备份到对象存储等等，ODC 的数据源也就开始支持一些传统数据库 和对象存储等等。
想要支持很多传统数据库，这个并不是很容易。产品的使用对用户是要尽可能简单，但产品的开发确实要深入去了解传统数据库的功能特点。
云趣数据库管控平台 QueryX
QueryX 是云趣科技推出的数据库管控产品，类似“数据库的堡垒机”的角色，为企业提供自主可控的数据库访问管控平台。
QueryX 也算是 OB 的生态产品之一，但不仅限于此。
QueryX 可以集成企业 AD域登陆系统 或者 SSO 登录接口。
支持用户和角色，支持按项目配置用户访问数据库权限。
QueryX 支持传统的关系数据库（ORACLE/MySQL/PostgreSQL/SQLServer）、国产数据库（OceanBase/TiDB/TDSQL/GoldenDB/GBase8a/DM8/GaussDB等）、云数据库（RDS/PolarDB/TDSQL/GaussDB/AzureSQL等）。
QueryX 支持 SQL开发和审核，数据脱敏、审计以及 API 对接等，也支持工单审批、企业内流程对接等。
在权限管控上除了常见那种表访问权限控制外，QueryX 还实现了“行级管控”功能。
这个适合税务行业特有的权限需求场景：组织上不同层级的管理人员只能查看其管理范围内允许的数据。这个挑战在于这些数据都在同一个表里，但是不同的用户看到的数据却不相同。一般大型企业组织里只要权限也跟组织层级有关时，都可以使用这个功能。
更多功能介绍可以参考文章：《QueryX：SQL解析更强大，审计能力更全面》。有需求的欢迎联系。
