我有一个项目，还有一个子项目。现在，我希望子项目使用与主项目相同的用户数据进行登录。本质上，我有点想使用主项目的users表（也许还有与用户相关的第二个表）。不过，这不是一条单向路，我希望用户也能够在子项目上创建帐户，然后该帐户对主项目也同样有效。
要注意的是：项目将不同的专用服务器用于其SQL数据库。 （不过，MariaDB的版本均为10或10.1）
我考虑了以下选项：
1）我只能在子项目中打开2个mysql实例，一个用于访问子项目数据，一个用于访问主项目中的用户数据。但是，这带来了很大的缺点：a）好，我打开了2个连接，这也可能会导致性能下降，并且b）我根本不能在users表上使用任何JOIN。
2）我听说有一个FEDERATED引擎，当某些使用FEDERATED引擎的表涉及到查询时，该引擎可用于自动进行远程调用。但是，MariaDB似乎不再支持此引擎。 （我也没有来进行测试，以查看它可能还会带来什么其他缺点。我读到某处该方法存在潜在的安全隐患，因为它很容易读出与主服务器的连接信息？）
3）我从未使用过复制，但是如果我正确地理解了这个系统，那么我基本上可以拥有第二个本地数据库作为主服务器的users表的从属，对吗？但是，我担心这迟早会导致问题，尤其是如果我考虑到将来使用主项目的用户表可能会有更多的子项目。当几台服务器尝试同时添加（或编辑）内容时，让许多服务器维护完全相同的数据听起来像是许多潜在的麻烦制造者。
4）通过OpenID或Oauth的中央登录表单目前不是可取的选择。现在，我希望每个项目都提供自己的注册/登录表格。
这些（或其他）方法中哪一种是最佳方法，并且对于此用例而言，易于设置/维护？
答案 0 :(得分：0)
尽管我投票关闭了基于观点的意见，但我还是会提出我的意见：创建要进行身份验证的中间服务，而中间服务会担心细节。
中间服务与两个数据库对话。它首先检查数据库A，然后检查数据库B。它可能会缓存结果。它可能使一个数据库优先于其他数据库。这就是您所编写的便捷REST API背后的业务逻辑。
现在，您的主项目和子项目针对正在运行的中间服务发出REST请求。请求可能非常简单：这些凭证有效吗？如果是，则在您的项目中建立一个会话。如果会话的可移植性很重要，请使用公共库从每个库中识别会话值。
这种体系结构感觉最合乎逻辑-各个部分是分开的，业务逻辑包含在各个单元中，没有太多机会出现不适当的冗余-但它在接近编写自己的身份验证的危险性方面处于危险之中。您可能会考虑继续努力，实施中间身份验证系统以使用已建立的协议（例如OAuth）或直接使用OAuth系统。