1. 行级权限概述
各位好，我是老赵。做BI这行十几年，踩过的坑不少，但要说最让人头疼的，还得是数据权限问题。今天咱们聊聊行级权限——说白了，就是不同人看同一张报表，只能看到跟自己相关的数据。
举个例子。你是销售总监，看全国业绩。销售经理小王，只能看华东区。销售员小李，只能看他自己的客户。同一张报表，数据自动过滤。这就是行级权限的核心。
一句话定义：行级权限（Row-Level Security, RLS）是一种数据访问控制机制，根据用户身份或属性，在查询时自动过滤数据行，确保用户只能看到被授权的数据。
为什么需要行级权限？
我在2018年给一家连锁零售企业做BI项目时，遇到过这么个事。他们全国有300多家门店，总部、大区、门店三个层级。一开始没做行级权限，结果所有店长都能看到全国数据。不到两周，就有店长拿着别家店的销售数据去挖墙脚。老板气得拍桌子。
你看，没有行级权限，问题就来了：
- 数据泄露风险——不该看的人看到了敏感数据
- 报表臃肿——全量数据加载，性能直线下降
- 用户体验差——一个销售员看全国几百万条记录，找自己的客户像大海捞针
- 合规问题——GDPR、个人信息保护法等法规要求数据最小化访问
我的经验：行级权限不是锦上添花，而是数据平台的刚需。尤其是多租户SaaS场景，没有行级权限，产品根本没法上线。
行级权限 vs 列级权限
很多新手容易把这两个概念搞混。我简单画个对比：
| 维度 | 行级权限 | 列级权限 |
|---|---|---|
| 控制粒度 | 数据行（记录） | 数据列（字段） |
| 典型场景 | 销售只能看自己的订单 | 普通员工看不到薪资列 |
| 实现方式 | WHERE 条件过滤 | SELECT 字段控制 |
| 性能影响 | 影响查询计划 | 影响数据传输量 |
| 复杂度 | 较高（需关联用户映射） | 较低（直接字段屏蔽） |
嗯，这里要注意。实际项目中，行级和列级权限经常组合使用。比如财务系统：区域经理能看到本区域所有门店的营收数据（行级），但看不到门店的利润率计算逻辑（列级）。
常见应用场景
我做了这么多项目，行级权限的应用场景基本可以归纳为三类：
1. 销售区域隔离
这是最常见的场景。我曾经给一家快消品公司做BI，他们的销售团队按大区划分：华北、华东、华南、西南。每个大区经理只能看自己区域的数据。实现起来其实不复杂：
-- 伪代码示例：行级权限过滤
SELECT *
FROM sales_order
WHERE region = CURRENT_USER.region
但坑在哪呢？有些销售同时负责多个区域，或者临时调岗。这时候权限映射表就得设计得灵活一些。
2. 多租户SaaS
这个场景更典型。你做一个SaaS产品，给100家公司用。所有数据存在同一个数据库里。A公司的CEO不能看到B公司的数据。怎么做？
我2019年给一个跨境电商SaaS平台做数据架构时，用的是租户ID隔离：
-- 多租户行级权限
SELECT *
FROM order_fact
WHERE tenant_id = CURRENT_TENANT_ID()
避坑指南：我曾经遇到过一个案例，开发人员忘了在关联查询里加租户过滤，结果A公司的订单详情里，莫名其妙出现了B公司的客户信息。这种bug一旦上线，就是严重的数据安全事故。所以多租户场景下，我建议在数据库层面强制RLS，而不是只靠应用层过滤。
3. 组织架构数据隔离
这个场景最复杂。公司有层级：集团→事业部→部门→小组→个人。上级能看到下级的数据，但下级看不到上级的。平级之间互相隔离。
实现方式通常有两种：
- 路径法：每个节点存一个路径字段，比如 "/集团/事业部A/部门1/小组X"，查询时用 LIKE 匹配
- 闭包表：维护一个祖先-后代关系表，查询时JOIN这个表
我个人更推荐闭包表。路径法虽然直观，但一旦组织架构调整，路径更新成本很高。闭包表虽然多一张表，但查询效率稳定，维护也方便。
核心逻辑总结：行级权限的本质，就是在数据查询时注入一个动态的WHERE条件。这个条件基于当前用户的身份、角色、组织归属等信息动态生成。
这张图把行级权限的知识体系串起来了。你想想看，不管是哪种场景，最终落地的都是那套核心逻辑：用户身份→权限映射→动态WHERE条件→数据过滤。后面的章节，我会带大家一步步把这个逻辑落地到实际报表中。