自己的第一个开源项目 db2llm

[Loocor]

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 密钥

安装

1. 克隆仓库

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

1. 安装依赖

bun install

1. 配置 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 启动。

使用方法

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

示例查询

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

数据库支持

字段类型

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

元数据

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

注意事项

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

许可证

MIT

[ferock]

db , 这个形状...

[Loocor]

@ferock 😂 啥奇怪的关注点

[twig]

,,,,
db

[EastLord]

貌似有不少同类型的产品

[Loocor]

@EastLord 嗯啊，不过我也是发了才知道 Chat2DB 这类产品。不过我这个就是个技术方案演示，算不得产品😂

[elffkdx]

楼主有微信吗？

[Alexf4]

昨晚简单撸了个 MySQL MCP Server, 感觉就是类似这种场景的。但是现在还要依赖一些支持 MCP 的组件。

[aminobody]

text2sql

[Loocor]

@elffkdx MTgyODAwNTg0MDU= 🤝

[Loocor]

@Alexf4 MCP Server 因该是更规范灵活的做法，但我没深入了解过 MCP 架构，就选了这种最简单的方式来实现了

[Loocor]

@aminobody 😂 还是交流好，这个 text2sql 还有 Chat2DB 之前都没留意。从 text2sql 官网看它的实现基础估计也是基于数据库的 meta 信息做文章

[Wxh16144]

@Loocor #10 https://github.com/modelcontextprotocol/servers/tree/main/src/sqlite 这个例子差不多🤔，大家都遵循 MCP 最好了

[Loocor]

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

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

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

[Greatshu]

博客园有个 chat2db ，感觉和你差不多

[Loocor]

@Greatshu 他那个更完整，是产品向的东西，我这个勉强算是个初期技术模板🥲