2

有没有人对这两个数据库库都有实践经验 -knex与mysql2?

经过一番谷歌搜索（例如在NPMCompare），我仍然很想知道，根据实际经验，这两种选择的优缺点是什么？

到目前为止，我清楚地看到使用knexover的唯一真正优势mysql2是它对 MSSQL、MySQL、PostgreSQL、SQLite3 和 Oracle 的普遍支持，而后者仅支持 MySQL，但由于目前我只专注于 MySQL， thisknex的功能似乎不太相关。

我会考虑的参数：

  • 性能和负载电阻；
  • 稳定性（生产就绪）；
  • 原生 ES8+ 支持（callback-hell-free，没有额外的Util.promisify包装，ESM/MJS支持）；
  • 简洁明了，越少越好。
4

1 回答 1

6

我在我的主要项目中使用 knex，我认为您正在尝试将苹果与橙子进行比较，因为 Knex 是一个查询构建器，它使用 (mysql2) 作为传输库（在使用 MySql 的情况下）。

我在 Knex 看到的好处是：

  1. 默认情况下防止 SQL 注入。
  2. 让您非常轻松地构建查询，而无需付出太多努力
  3. 让您像编写 javascript 函数一样编写查询（在我看来，这是一个很大的优势）。

由于＃3在我看来是一个如此大的优势，因此最好证明它：

认为你有 2 个端点

  1. /users/list- 假设返回用户列表 ( {id, name})
  2. /users/:id- 假设返回具有相同结构的单个用户。

你可以像这样实现它。

async function getAllUsers() {
  return db('users').columns('id', 'name'); //think that this can consist of many joins
}

async function getUserById(userId) {
  return getAllUsers().where('id', userId);
}

看看如何getUserById重用相同的查询（可能真的很复杂），并且只是“添加”它需要的限制。

性能方面，我不认为这种抽象有很大的成本，（我还没有注意到任何性能问题）

我不确定你所说的稳定性是什么，但 Knex 有一个非常酷的 TS 支持，它可以使你的查询强类型化。

interface User {
  id: number;
  name: string;
}

const users = await db<User>('users').columns('id', 'name'); // it will autocomplete the columns names & users will be of type User[] automatically.

结合使用@typed-code/schemats从数据库自动生成这些数据库类型，它使工作和重构变得更好。

从 ES6 开始，Knex 默认支持 Promises 和回调，因此您可以选择适合您的任何内容。

我正在使用的其他很酷的功能是在案例之间自动转换，我的数据库对于表和列名称具有蛇案例样式，但在我的节点中，我使用骆驼案例，使用knex-stringcase插件。

迁移，允许您定义如何使用代码构建/升级架构，这可以帮助您从 CI 自动更新生产架构。

Mysql2 是数据库之上的低级驱动程序。

于 2020-05-02T12:36:31.703 回答