https://github.com/loocor/db2llm

仅仅是个原型，用于验证传统系统的数据库与 LLM 互通的方式的 ...

兄弟们帮我点点 star 我去换个 idea 的授权呢 🫣

DB2LLM 最小化原型

概述

DB2LLM 是一个将 SQLite 数据库的元数据与 RESTful API 和大型语言模型（ LLM ）结合的最小化原型。它允许用户通过自然语言与数据库进行交互，无需编写 SQL 查询或了解数据库结构。当前为便于演示，使用 SQLite 数据库，实际使用时，请使用自己的数据库并更新相关的配置。

功能特点

提供用户对话窗口，支持配置 LLM 的 API 地址和授权密钥
支持用户指定 SQLite 数据库文件
自动分析数据库结构，提取元数据信息
- 表结构和字段信息
- 字段枚举值映射（如性别：男/女、male/female 等）
- 主键、外键和索引信息
动态生成 RESTful API ，用于数据库操作
智能会话管理
- 支持上下文记忆，理解后续查询
- 会话超时自动清理（ 30 分钟）
- 结果摘要生成
将用户自然语言查询转换为 API 请求
执行 API 请求并返回结果
支持多步骤复杂查询

技术栈

运行时: Bun
Web 框架: Hono
数据库: SQLite
ORM: TypeORM
LLM 集成: OpenAI API 及兼容接口

快速开始

前提条件

安装 Bun 运行时
准备一个 SQLite 数据库文件
获取 OpenAI API 密钥或其他兼容的 LLM API 密钥

安装

克隆仓库

git clone https://github.com/loocor/db2llm.git
cd db2llm

安装依赖

bun install

配置 LLM 修改 config/config.yaml 文件：

server:
  port: 3000
  host: "localhost"

database:
  tempDir: "db2llm"
  defaultName: "db2llm.sqlite"
  connection:
    synchronize: false
    logging: ["error", "warn"]

llm:
  provider: "deepseek"
  openai:
    model: "deepseek-chat"
    temperature: 0.3
    defaultApiUrl: "https://api.deepseek.com/v1"
    apiKey: "sk-4c907ed3eed5468db793b6f431e9a28c"

ui:
  title: "DB2LLM - 数据库对话助手"
  welcomeMessage: "欢迎使用 DB2LLM 数据库对话助手！请先连接数据库和配置 LLM API 。"
  readyMessage: "我已准备好，跟我来聊吧！"

支持的 LLM 提供商：

DeepSeek API （默认）
OpenAI API
Azure OpenAI
Claude API
其他兼容 OpenAI API 格式的服务

运行

bun run dev

应用将在 http://localhost:3000 启动。

使用方法

打开浏览器访问 http://localhost:3000
上传 SQLite 数据库文件
输入 LLM API 密钥（和可选的 API 地址）
点击"连接"按钮
连接成功后，在对话框中输入自然语言查询
系统将自动处理查询并返回结果

示例查询

"显示所有用户信息"
"查找所有女性用户"
"统计男性用户数量"
"添加一个新用户，姓名为李四，性别男，年龄 30 岁"
"更新 ID 为 5 的用户的电话号码为 13812345678"
"删除 ID 为 10 的用户"
"再找找看"（基于上下文的后续查询）

数据库支持

字段类型

基本类型：INTEGER, TEXT, NUMBER 等
支持自定义枚举值映射，如：
- 性别：['女', 'female', 'f', '2', '0'] -> 女性
- 状态：['active', '1', '启用'] -> 启用

元数据

表结构信息
字段属性（主键、非空等）
字段枚举值映射
外键关系
索引信息

注意事项

本项目是一个概念验证原型，不建议在生产环境中使用
未实现用户认证和授权机制
未优化大型数据库的性能
API 密钥直接在前端输入，存在安全风险
会话数据存储在内存中，服务重启后会丢失

许可证

MIT

Loocor

176 天前

@Wxh16144 确实，遵循一致的规范有必要，下来得学习下 MCP 。

代码上我大概看了下，不知道这个方案是如何处理表、字段命名一致性的问题。看起来它完全依赖于 LLM 的判断来生成表名，这可能会导致几个潜在的问题：
1 、命名不一致：
- 同样的概念可能会用不同的表名（ customers/clients/users ）
- 不同的会话可能产生不同的命名选择
- 缺乏命名规范的强制执行
2 、结构不一致：
- 字段名称可能不统一（ first_name/firstname/fname ）
- 数据类型可能不一致（ VARCHAR/TEXT, INT/INTEGER ）
- 缺乏字段定义的标准化
3 、关系混乱：
- 外键引用可能使用不同的表名
- 索引命名可能不统一
- 缺乏关系模式的规范

db2llm 不同，默认是 db first 模式，现在的例子里是通过已有的 meta 信息来约束 llm 生成的请求，从而保证请求一致性的问题。但是除了 mcp 规范的欠缺外，其实对比前面这几个方案来看创建记录没问题但要新增表的话，一样也会出现一致性的毛病，我看看有没有其他的模式来处理这个问题

自己的第一个开源项目 db2llm