去年 ChatGPT 在科技圈大火，到今年彻底破圈。各个领域都有相应的一些产品，数据库领域集中在 AI + SQL，自然语言转 SQL，或者利用自然语言来管理数据库等。今天我们来体验一下该领域的 SQLChat 这款 AI 数据库客户端。

今天我们预设一个场景，实现基于 RBAC 的权限表结构，同时进行一定的 SQL 语句分析，表结构变更等工作。看一下再 AI 的加持下，能否进一步提升我们在数据库的管理，甚至说库表设计上能给我们一些启发，实现人与 AI 对数据库的协同管理。

RBAC 实现

1. 查看当前表结构

我们在开始前，先查看一下当前数据库相关表结构。

表结构和源数据库中的一致。

2. 画出 RBAC 模型下的 ER 图

根据它所给出的 RBAC 模型 ER 图，确实没有问题，角色表，权限表，角色权限关系表。并把其中的关系也表述清楚了。但是还比较粗略，需要我们进一步补充细节实现，例如我们希望权限能够基于请求路由来进行控制，看它调整之后的 ER 图如何。

3. 调整权限表

对我们的需求理解得比较准确，之前实现的三个表 roles, permissions, role_permissions 它还没有忘记，根据具体的业务需求来决定资源和权限的关系，它目前是进行了拆分，在相对不复杂的权限管理中，可以将资源和权限关系合并。

4. 生成具体的表结构

ER 图也画好了，让它调整一下表结构后，接下来让我们生成对应的 DLL

它的回答如下

```

Sure, here's an example of a DDL for a RBAC permission table structure that looks up resource relationships by permissions:

CREATE TABLE roles (    role_id INTEGER PRIMARY KEY,    role_name VARCHAR(50) NOT NULL);
CREATE TABLE resources (    resource_id INTEGER PRIMARY KEY,    route VARCHAR(255) NOT NULL,    method VARCHAR(10) NOT NULL);
CREATE TABLE permissions (    permission_id INTEGER PRIMARY KEY,    permission VARCHAR(50) NOT NULL);
CREATE TABLE permission_resources (    permission_id INTEGER NOT NULL,    resource_id INTEGER NOT NULL,    FOREIGN KEY (permission_id) REFERENCES permissions(permission_id),    FOREIGN KEY (resource_id) REFERENCES resources(resource_id),    PRIMARY KEY (permission_id, resource_id));
CREATE TABLE role_permissions (    role_id INTEGER NOT NULL,    permission_id INTEGER NOT NULL,    FOREIGN KEY (role_id) REFERENCES roles(role_id),    FOREIGN KEY (permission_id) REFERENCES permissions(permission_id),    PRIMARY KEY (role_id, permission_id));

In this structure, there are four tables: roles, resources, permissions, and permission_resources. The roles table contains information about the different roles in the system, such as role_id and role_name. The resources table contains information about the different resources that can be accessed, such as resource_id, route, and method. The permissions table contains information about the different permissions that can be granted, such as permission_id and permission. The permission_resources table is a junction table that links the permissions and resources tables together, allowing for a many-to-many relationship between them. It contains foreign keys to both the permissions and resources tables, allowing for the assignment of specific resources to specific permissions. Finally, the role_permissions table links the roles and permissions tables together, allowing for the assignment of specific permissions to specific roles. It contains foreign keys to both the roles and permissions tables, allowing for the assignment of specific roles to specific permissions.

```

给出的表结构还不错，其中的一些小细节值得表扬，在 resources 表中，method 字段长度限制比较合理。

5. 生成 10 条权限资源数据用于测试

表结构也生成了，接下来我们生成 10 条权限资源数据测试一下

它的回答如下

```

Sure, here's an example of 10 permission resource data for testing:

INSERT INTO roles (role_id, role_name) VALUES (1, 'admin');INSERT INTO roles (role_id, role_name) VALUES (2, 'user');
INSERT INTO resources (resource_id, route, method) VALUES (1, '/users', 'GET');INSERT INTO resources (resource_id, route, method) VALUES (2, '/users/:id', 'GET');INSERT INTO resources (resource_id, route, method) VALUES (3, '/users', 'POST');INSERT INTO resources (resource_id, route, method) VALUES (4, '/users/:id', 'PUT');INSERT INTO resources (resource_id, route, method) VALUES (5, '/users/:id', 'DELETE');
INSERT INTO permissions (permission_id, permission) VALUES (1, 'view_users');INSERT INTO permissions (permission_id, permission) VALUES (2, 'create_users');INSERT INTO permissions (permission_id, permission) VALUES (3, 'edit_users');INSERT INTO permissions (permission_id, permission) VALUES (4, 'delete_users');
INSERT INTO permission_resources (permission_id, resource_id) VALUES (1, 1);INSERT INTO permission_resources (permission_id, resource_id) VALUES (1, 2);INSERT INTO permission_resources (permission_id, resource_id) VALUES (2, 3);INSERT INTO permission_resources (permission_id, resource_id) VALUES (3, 2);INSERT INTO permission_resources (permission_id, resource_id) VALUES (3, 4);INSERT INTO permission_resources (permission_id, resource_id) VALUES (4, 5);

In this example, we have created two roles: admin and user. We have also created five resources: /users (GET), /users/:id (GET, POST, PUT, DELETE). We have created four permissions: view_users, create_users, edit_users, and delete_users. Finally, we have assigned the appropriate resources to each permission using the permission_resources table.

```

这次的生成比较出乎我的意料，它能够理解表结构之间的关联，并且具体的测试数据之间的关联性基本正确。各个表字段类型，长度都符合刚才定义的表结构。

6. 最后，将原有的 employees 表和 roles 表关联起来即可

它的回答出现了一些问题

```

Sure, to associate the employees table with the roles table, you can add a foreign key column to the employees table that references the roles table. Here's an example of how you can modify the employees table to include a foreign key column:

CREATE TABLE employees (    employee_id INTEGER PRIMARY KEY,    first_name VARCHAR(50),    last_name VARCHAR(50),    email VARCHAR(100),    phone_number VARCHAR(20),    hire_date DATE,    job_id INTEGER,    salary NUMERIC(8,2),    commission_pct NUMERIC(2,2),    manager_id INTEGER,    department_id INTEGER,    role_id INTEGER,    FOREIGN KEY (role_id) REFERENCES roles(role_id));

In this modified employees table, we have added a new column called role_id that references the role_id column in the roles table. This allows us to associate each employee with a specific role. We have also added a foreign key constraint to ensure that the role_id value in the employees table references a valid role_id value in the roles table.

```

可以和最开始的表结构进行对比，我们在没有变动 employees 表的情况下，虽然它确实把 employees 表和 roles 表关联起来了，但是 employees 表原有结构与开始不一致，它没有 "记住" 刚才的表结构。

总结

最后小小的总结一下，SQLChat 我使用也有好几天了，给我的使用感受还是比较不错的，成熟度也比较高，跟之前玩具级别的产品不一样。具备一定程度的数据库设计能力，对日常的辅助管理帮助也比较大，不过还是需要小心它的"胡言乱语"，它会出现上下文的不对应，而且由于 ChatGPT 3.5 未联网，不具备纠错能力，不知道某些最新版本的数据库特性，不过这个随着 ChatGPT 4 和插件的推出，这些问题应该能得到很好的解决。