RESTful API的SQL数据库结构

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

最初，尽管每个资源一个表都是一个不错的方法，但是现在我担心这会导致在资源链越远的地方，表成指数增长。

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

如下访问销售资源

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

因此，如果有10个用户，每个用户有10个客户，并且每个客户有10个销售量，那么随着我们走的资源链越远，表的大小就越大。

我相当有信心SQL可以应付大表，但是我不确定读写会如何减慢速度。上面的示例可能没有说明，但是我的api会在我们走的资源链中越来越多地进行更多的写入和读取。因此，在这种情况下，数据库中最大的表的读取和写入次数要比较小的表更多。

在运行查询之前，也有必要联接表。原因是我允许每个用户拥有一个具有相同名称的客户端。为避免获取错误的客户端数据，{userID}将users表和clients表连接在一起。销售情况也是如此。联接大表并运行会进一步降低读写速度吗？

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

别。

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

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

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

请注意，您当前正在将内部数据库标识符（UserID / ClientId / SalesID）暴露给外界。这可能适合您的情况，但通常<entity>ID在RESTful API中使用。

关系数据库（因此为SQL）非常擅长从巨大的表中查找一（或几）行。这就是索引的用途。他们在处理联接方面也非常出色。你真的没有问题。在这两行之间，您基本上是在询问如何进行多租户数据库设计。我建议您在询问其他问题之前先阅读多租户数据架构。选择一种模式（独立数据库，共享数据库独立模式，共享数据库共享模式），然后讨论具体细节。现在，您仅设想最后一种模式，而没有考虑利弊。阅读。

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

只是为了补充此处已经说过的内容-您可能希望在实际的API与您的数据库层之间建立一个接口。它使添加缓存和摘要表更加容易。