RESTful API 的 SQL 数据库结构

Question

我正在创建一个 RESTful API。我正在努力决定围绕我的资源设计我的数据库表的最佳方式。

最初，我认为每个资源一个表是一个很好的方法，但我现在担心这会导致你在资源链的下游形成指数级更大的表。

例如，假设我有三个资源 - 用户、客户、销售。用户是我的 api 的订阅者，客户是用户的客户，销售是每个客户对用户帐户的购买。

一个销售资源的访问方式如下

GET /users/{userID}/clients/{clientID}/sales/{salesID}

因此，如果有 10 个用户，每个用户有 10 个客户，并且每个客户有 10 个销售，那么表的大小会随着资源链越往下而越大。

我相当有信心 SQL 可以处理大表，但我不确定读取和写入将如何减慢速度。上面的例子可能没有说明它，但我的 api 将有越来越多的写入和读取我们走的资源链越远。因此，我的数据库中最大的表将比较小的表被读取和写入更多次。

在运行查询之前连接表也是必要的。原因是我允许每个用户有一个同名的客户端。为避免获取错误的客户端数据，用户表和客户端表由 {userID} 连接。销售也是如此。加入大表并运行读写会进一步减慢速度吗？

Answer 1

我正在努力决定围绕我的资源设计我的数据库表的最佳方式。

别。

根据RESTful 原则设计您的 API ，根据规范化原则设计您的数据库。一个不需要影响另一个。

您的数据库不应包含SaleResource表，而应包含Sale（或采购/订单）表。该表将包括唯一标识销售的主键和相关用户和客户表的外键。

您的 REST api 将对由 标识的资源的请求转换为GET /users/{userID}/clients/{clientID}/sales/{salesID}适当的数据库查询，检索行，构造表示销售的资源并将其返回给客户端。

请注意，您当前正在向外界公开看似内部数据库标识符 (UserID/ClientId/SalesID) 的内容。它可能适合您的情况，但通常<entity>ID感觉不适用于 RESTful API。

Answer 2

关系数据库（因此是 SQL）非常擅长从大表中定位一行（或几行）。这就是索引的用途。他们在处理连接方面也非常出色。你真的没有问题。字里行间，您基本上是在询问如何进行多租户数据库设计。我建议您在提出进一步问题之前阅读多租户数据架构。选择其中一种模式（单独数据库、共享数据库单独模式、共享数据库共享模式），然后我们再讨论具体情况。现在你只设想了最后一种模式，而没有考虑利弊。阅读。

附带说明：您不需要user/{userID}在 URI 中。您从身份验证信息中知道租户（用户 ID）。