开源项目的首要挑战是找出最佳的贡献者协作方式 开源项目要面对的首要挑战之一是如何在贡献者之间沟通。这里有很多的选择：论坛、聊天频道、 工单 （ issue ） 、邮件列表、 拉取请求 （ pull request ） 等等。我们该选择哪个合适的来使用，我们又该如何做呢？ 令人遗憾的是，项目本身往往不愿做出约束性的决定，而是选择“上述所有”。这就导致了一个支离破碎的社区：有些人使用 Slack/Ma

🚀 新功能 支持不同数据库引擎配置不同 SQL 审核规则。 支持为工单事件配置企业微信私聊通知。 支持连接到 Redis 哨兵架构和原生集群。 在项目级别，支持设置： 是否允许在工单创建后修改 SQL 语句。 是否自动完成已发布的工单。 🔔 重大变更 多租户配置项已从项目级别移动至数据库分组。 🎄 改进 -「取消」工单改名为「关闭」工单。 添加更详细的任务执行日志。 在添加实例时，增加了 SSL

🚀 新功能 支持 DynamoDB。 支持独立的 SQL 审核工单。 支持为工单事件配置 Slack 私信通知。 支持 PostgreSQL 的 DML 变更事前备份。 为 SQL Server 添加 SQL 审核规则：禁止冗余索引。 🔔 重大变更 创建多数据库工单时，不同数据库会共享同一份 SQL 语句。 🎄 改进 支持在 SQL 编辑器中管理实例和环境。 支持设置数据查询者和导出者的最大过期时

本周我们发布了 SQLE 3.2405.0 正式版！主要更新概览： 社区版 针对工单变更功能做了整体 UI 交互优化，提升工单使用体验！ 企业版 SQL 工单支持存储过程等复杂语法上线 SQL 工单支持变更上线顺序，保障上线成功率 CloudBeaver 工作台支持审计操作记录 以下是 SQLE 3.2405.0 正式版的新功能解读。 🎈 新功能 企业版 1. SQL 工单支持存储过程等复杂语法上

运营商CRM系统在业务运行过程中会产生大量的工单（包括过程记录和状态记录）及日志数据，这些数据主要用于查询、统计和分析。随着时间的推移，这些数据成为了历史数据，且一般是一年以上的历史数据。 某运营商CRM历史工单系统数据增量约为12TB/年。为将历史数据与热数据分离开来，因此需将历史数据独立存储。为此，计划新建CRM历史工单系统，一方面降低生产数据库的存储和查询压力，另一方面希望能有效地降低数据存

🎈 新功能 社区版 工单详情支持查看 SQL 所在文件及行数 本期支持展示工单中 SQL 的所属文件及所在行数。如您发现工单中的 SQL 审核不通过、上线有问题，需要回到原 SQL 文件中进行修改时，可以通过该功能快速定位 SQL 所在的位置，从而减少定位 SQL 所需的时间消耗。   企业版 1. 项目业务信息支持统一管理 本期支持导入项目信息及项目相关的业务信息。当您初始化平台时，可以批量导入