4、数据源连接与管理：支持的数据源类型、配置、权限与缓存策略

好，咱们进入第四章。这一章我打算聊聊数据源。说实话，在低代码平台里，数据源就是整个报表和仪表盘的「心脏」。你界面做得再花哨，数据拉不出来，或者拉出来是错的，那一切都白搭。

我在好几个项目里都遇到过这种情况——业务方兴冲冲地搭好了仪表盘，结果一刷新，数据加载了半分钟还没出来。后来一查，是数据源配置没做优化。嗯，咱们今天就把这块彻底讲透。

4.1 支持的数据源类型

低代码平台要能干活，首先得「吃得下」各种数据。我个人习惯把数据源分成四大类：

• 数据库：MySQL、PostgreSQL、SQL Server、Oracle 这些关系型数据库，还有 ClickHouse、Doris 这类分析型数据库。这是最常用的。
• API：RESTful API、GraphQL。适合对接第三方系统，比如 CRM、ERP。
• Excel / CSV：临时数据、小批量数据。业务人员最爱用这个。
• 其他：比如 Redis、MongoDB、Elasticsearch。看平台定位，有些会支持。

你想想看，一个成熟的低代码平台，至少得覆盖前三种。为什么？因为真实场景里，数据来源从来不是单一的。

4.2 数据源配置

配置数据源，听起来简单，其实坑不少。我见过最离谱的配置——有人把数据库密码明文写在 URL 里，还上传到了 Git。嗯，咱们得规范起来。

4.2.1 数据库配置

典型的数据库连接配置长这样：

{
  "type": "mysql",
  "host": "192.168.1.100",
  "port": 3306,
  "database": "report_db",
  "username": "report_user",
  "password": "encrypted_password_here",
  "extraParams": {
    "useSSL": false,
    "characterEncoding": "UTF-8",
    "connectTimeout": 5000
  }
}

这里要注意几点：

• 密码必须加密存储。我习惯用 AES 加密，密钥放在环境变量里。
• 连接池大小要可配置。默认 10 个连接，但高并发场景下得调大。
• 超时时间别设太长。5 秒够了，不然页面卡死。

4.2.2 API 配置

API 数据源稍微复杂一点。你需要配置：

• 请求地址：支持动态参数，比如 https://api.example.com/orders?date={startDate}
• 认证方式：Basic Auth、Bearer Token、API Key
• 请求方法：GET、POST
• 请求头：Content-Type、自定义头
• 响应解析：JSON Path 提取数据

4.2.3 Excel / CSV 配置

这个相对简单。主要配置项：

• 文件上传：支持拖拽上传
• 编码格式：UTF-8、GBK（国内常见）
• 分隔符：逗号、制表符、自定义
• 表头行：第几行是表头
• 数据类型推断：自动识别数字、日期、文本

嗯，这里有个坑——Excel 文件里经常有合并单元格、空行、特殊字符。我建议上传后先做一次「数据清洗预览」，让用户确认没问题再导入。

4.3 数据源权限管理

权限这块，说白了就是「谁能看到什么数据」。我在一个金融项目里吃过亏——报表开发人员能看到所有客户的交易明细，这显然不行。

我建议分三层来控制：

权限层级	控制粒度	典型场景
数据源级	能否访问某个数据源	财务人员只能访问财务数据库
表/视图级	能否访问某张表	普通用户只能看订单表，不能看用户表
行级	能否看到某行数据	销售只能看自己负责的客户

行级权限是最难做的。我常用的方案是「动态 SQL 过滤」：

-- 原始查询
SELECT * FROM orders

-- 加了行级权限后
SELECT * FROM orders 
WHERE salesperson_id = current_user_id()

这样，同一个报表，不同人看到的数据不一样。但要注意性能——行级过滤字段最好有索引。

4.4 数据源缓存策略

缓存，是提升报表加载速度的「杀手锏」。但缓存用不好，数据就变成「过期面包」了。

4.4.1 缓存层级

我一般分三层缓存：

• 查询结果缓存：同一个 SQL 在短时间内重复查询，直接返回缓存结果。
• 数据源连接缓存：复用数据库连接，避免频繁创建连接。
• 元数据缓存：表结构、字段信息这些，变化频率低，可以缓存很久。

4.4.2 缓存策略配置

每个数据源都可以单独配置缓存策略：

{
  "cacheEnabled": true,
  "cacheTTL": 300,          // 缓存有效期，单位秒
  "cacheMaxSize": 100,      // 最大缓存条目数
  "cacheEvictionPolicy": "LRU",  // 淘汰策略：LRU、LFU、FIFO
  "cacheRefreshOnRead": true // 读取时自动刷新
}

这里我分享一个经验：不要对所有数据源用同样的缓存策略。

• 实时性要求高的（比如交易数据）：缓存 30 秒就够了。
• 变化慢的（比如客户信息）：缓存 10 分钟没问题。
• 静态数据（比如地区字典）：缓存 1 小时甚至更长。

4.4.3 缓存失效机制

缓存最怕什么？数据变了，缓存没更新。我常用的方案：

• 定时失效：到了 TTL 自动清掉。
• 手动刷新：用户点击「刷新」按钮时强制清缓存。
• 事件驱动：数据源有更新时，主动通知缓存层失效。

4.5 小结

这一章内容不少，咱们快速回顾一下：

• 数据源类型要覆盖数据库、API、Excel/CSV，这是基本功。
• 配置数据源时，密码加密、连接池、超时设置一个都不能少。
• 权限管理要分三层，行级权限用动态 SQL 实现，千万别在前端做。
• 缓存策略要差异化，实时数据短缓存，静态数据长缓存。

下一章咱们会聊「报表设计器的核心功能」，到时候我会手把手教你搭一个可拖拽的报表编辑器。嗯，敬请期待。