如何对items表查询强制添加siteId条件约束？

既然你已经清楚应用层的实现方式，那咱们来聊聊数据库层面的几种可行方案，从不同数据库特性出发，满足你「无siteId条件查询就报错」的需求：

1. 行级安全策略（Row-Level Security, RLS）（适用于PostgreSQL、SQL Server等支持RLS的数据库） #

这是最优雅的方案之一，能在数据库层面直接对表的访问做约束，应用层几乎不需要修改代码。以PostgreSQL为例：

首先开启Items表的RLS：

ALTER TABLE items ENABLE ROW LEVEL SECURITY;

然后创建一个策略，只允许携带有效siteId的查询——这里可以结合会话变量，让应用在查询前设置当前访问的siteId，或者直接强制查询语句中必须包含siteId条件：

-- 策略1：强制查询必须指定siteId，且对应的Site存在
CREATE POLICY require_valid_site_id ON items
FOR SELECT USING (
  siteId IS NOT NULL 
  AND EXISTS (SELECT 1 FROM sites WHERE id = siteId)
);

如果用户执行SELECT * FROM items，因为没有满足siteId IS NOT NULL的过滤条件，会返回空结果。如果想要直接报错而不是返回空，你可以结合自定义函数抛出异常：

CREATE OR REPLACE FUNCTION check_site_id_required()
RETURNS BOOLEAN AS $$
BEGIN
  IF current_setting('app.site_id', true) IS NULL THEN
    RAISE EXCEPTION 'siteId is required for querying items table';
  END IF;
  RETURN TRUE;
END;
$$ LANGUAGE plpgsql;

-- 更新策略，调用检查函数
CREATE POLICY require_site_id ON items
FOR SELECT USING (check_site_id_required() AND siteId = current_setting('app.site_id')::int);

应用层只需要在查询前设置会话变量：SET app.site_id = '1';，就能正常查询对应site的items了。

优点：透明性高，应用可以保持原有查询逻辑；权限控制精细。
缺点：依赖数据库对RLS的支持，MySQL等数据库不支持。

2. 封装查询为存储过程/函数（几乎所有主流数据库都支持） #

通过创建带参数的存储过程或函数，强制用户必须传入siteId，否则直接抛出错误，同时还能验证site是否存在。以PostgreSQL和MySQL为例：

PostgreSQL函数示例： #

CREATE OR REPLACE FUNCTION get_items(p_siteId INT)
RETURNS SETOF items AS $$
BEGIN
  -- 检查siteId是否为空
  IF p_siteId IS NULL THEN
    RAISE EXCEPTION 'siteId parameter is required - cannot query items without it';
  END IF;
  -- 验证对应的Site是否存在
  IF NOT EXISTS (SELECT 1 FROM sites WHERE id = p_siteId) THEN
    RAISE EXCEPTION 'Site with id % does not exist', p_siteId;
  END IF;
  -- 返回符合条件的记录
  RETURN QUERY SELECT * FROM items WHERE siteId = p_siteId;
END;
$$ LANGUAGE plpgsql;

然后撤销普通用户对items表的直接查询权限，只授予函数执行权限：

REVOKE SELECT ON items FROM public;
GRANT EXECUTE ON FUNCTION get_items(INT) TO public;

用户只能通过调用函数查询：SELECT * FROM get_items(1);，不传参数或者传无效siteId都会直接报错。

MySQL存储过程示例： #

DELIMITER //
CREATE PROCEDURE get_items(IN p_siteId INT)
BEGIN
  IF p_siteId IS NULL THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'siteId parameter is required - cannot query items without it';
  END IF;
  IF NOT EXISTS (SELECT 1 FROM sites WHERE id = p_siteId) THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = CONCAT('Site with id ', p_siteId, ' does not exist');
  END IF;
  SELECT * FROM items WHERE siteId = p_siteId;
END //
DELIMITER ;

同样要控制权限：

REVOKE SELECT ON items FROM 'your_app_user'@'%';
GRANT EXECUTE ON PROCEDURE get_items TO 'your_app_user'@'%';

优点：兼容性极强，几乎所有数据库都支持；能精确控制错误信息，还能额外做site存在性验证。
缺点：应用层必须改为调用存储过程/函数，不能直接写SELECT语句，灵活性稍差。

3. 受限视图+权限控制（简单但局限性大） #

创建一个只能通过siteId过滤的视图，然后禁止用户直接访问items表：

CREATE VIEW vw_items AS
SELECT * FROM items WHERE siteId IS NOT NULL;

-- 撤销普通用户对原表的查询权限
REVOKE SELECT ON items FROM public;
-- 授予视图查询权限
GRANT SELECT ON vw_items TO public;

不过这个方案有个明显局限：用户查询SELECT * FROM vw_items会返回所有带siteId的items，而不是报错。如果要强制必须带siteId条件，你可以创建参数化视图（比如PostgreSQL的函数式视图），本质上和第二种方案类似。

优点：实现简单，不需要复杂逻辑。
缺点：无法强制报错，只能限制返回范围；如果用户有更高权限，还是能绕过视图访问原表。

总结 #

如果你的数据库支持RLS（比如PostgreSQL、SQL Server），优先选择行级安全策略，兼顾透明性和安全性；如果是MySQL这类不支持RLS的数据库，存储过程/函数是最可靠的方案；受限视图适合只需要限制访问范围、不需要强制报错的场景。

内容的提问来源于stack exchange，提问作者Ben