✅派聪明 RAG 项目的库表设计

一、用户表 (users)

users 表不仅存储了基础的用户认证信息（用户名、加密密码），更重要的是实现了基于组织的权限管理体系。通过 role 字段区分普通用户和管理员， org_tags 字段支持用户归属多个组织标签（逗号分隔），而 primary_org 则标识用户的主要组织归属。这种设计使得派聪明能够在企业环境中实现细粒度的多租户权限控制，确保不同组织的用户只能访问属于自己组织的知识资源。

字段名	数据类型	是否主键	描述
id	BIGINT	是	用户唯一标识
username	VARCHAR(255)	否	用户名，唯一
password	VARCHAR(255)	否	加密后的密码
role	ENUM('USER', 'ADMIN')	否	用户角色
org_tags	VARCHAR(255)	否	用户所属组织标签，多个用逗号分隔
primary_org	VARCHAR(50)	否	用户主组织标签
created_at	TIMESTAMP	否	创建时间
updated_at	TIMESTAMP	否	更新时间

建表语句：

CREATE TABLE users (
    id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '用户唯一标识',
    username VARCHAR(255) NOT NULL UNIQUE COMMENT '用户名，唯一',
    password VARCHAR(255) NOT NULL COMMENT '加密后的密码',
    role ENUM('USER', 'ADMIN') NOT NULL DEFAULT 'USER' COMMENT '用户角色',
    org_tags VARCHAR(255) DEFAULT NULL COMMENT '用户所属组织标签，多个用逗号分隔',
    primary_org VARCHAR(50) DEFAULT NULL COMMENT '用户主组织标签',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_T...

热门评论

那就这样吧 2026年01月26日 16:34

@派聪明用户主**标签页有什么作用

回复1 取消回复

派聪明 2026年01月26日 16:35

用户主**标签（`primary_org`）在系统中起到**核心权限锚点**的作用，具体功能如下： --- ### **1. 权限控制的默认依据** - 当用户访问资源（如文档、知识库）时，系统优先以 `primary_org` 作为其默认**权限标识。 - 例如：技术部用户的 `primary_org` 为 `tech`，则默认只能访问技术部标签下的资源，即使该用户也属于其他**（如 `hr`）。 --- ### **2. 多**场景的简化管理** - 用户可能属于多个**（通过 `org_tags` 字段存储多个标签，如 `tech,hr`），但 `primary_org` 明确其**主要归属**。 - 系统在权限校验、数据隔离等场景中，优先使用 `primary_org` 作为判断依据，避免复杂的多**交叉权限逻辑。 --- ### **3. 文档与**的绑定** - 用户上传文件时，系统自动将文件的 `org_tag` 字段设置为用户的 `primary_org`（除非手动指定）。 - 确保用户上传的文档默认归属其主**，实现****级知识隔离**（如技术部文档默认仅技术部可见）。 --- ### **4. 权限策略的快速过滤** - 在向量检索（如 `document_vectors` 表）时，系统通过 `org_tag` 与用户的 `primary_org` 匹配，快速过滤无权访问的文档。 - 提升检索效率，避免用户看到非主**的内容。 --- ### **5. **层级结构的映射** - `primary_org` 的值需存在于 `organization_tags` 表的 `tag_id` 字段中，确保用户的主**是系统定义的有效**节点。 - 支持**层级（如 `company → dept → team`），用户的主**可映射到任意层级节点。 --- ### **总结** `primary_org` 是**多租户权限体系的核心锚点**，通过明确用户的主要**归属，简化权限管理、实现数据隔离、优化检索效率，同时支持灵活的多**扩展能力。

回复取消回复

3 条评论

忧伤的雨 2026年03月06日 19:57

引用原文：四、分片表 (chunk_info)

@派聪明是文件刚分完片就存储到数据库中吗

派聪明 2026年03月06日 19:57

根据参考资料中的 **chunk_info 表设计**，分片信息是在文件分片完成后**立即存储到数据库**的。具体逻辑如下： ### 关键依据： 1. **分片表的作用** `chunk_info` 表专门用于存储文件分片的元数据（如分片索引、分片MD5、存储路径等），每个分块对应一条独立记录。 2. **存储时机** 当系统将文件切分成多个分块（chunk）后，会**立即为每个分块生成元数据**，并写入 `chunk_info` 表。例如： - 分片完成后，系统记录 `file_md5`（关联文件）、`chunk_index`（分片序号）、`chunk_md5`（分片校验值）、`storage_path`（存储位置）等字段。 3. **与上传流程的关联** - 分片操作是文件上传流程的一部分（参考 `file_upload` 表的 `status` 字段追踪上传状态）。 - 分片完成后，元数据直接写入数据库，确保后续处理（如合并、向量化）能通过 `file_md5` 关联到分片信息。 ### 为什么需要立即存储？ - **断点续传支持**：若上传中断，可通过数据库中的分片记录恢复进度。 - **并行处理**：分片信息存储后，系统可并行处理不同分块（如向量化）。 - **数据一致性**：避免分片完成后因异常导致元数据丢失。 ### 结论： **是的，文件分片完成后，分片元数据会立即写入 `chunk_info` 表**，为后续的文件合并、向量化处理提供基础。

zzj 2025年12月12日 23:47

为什么tagid不设置为bigint

一、用户表 (users)

热门评论

3 条评论

目录

划词评论