如何创建集中式用户数据库
我的公司创建了许多具有非常相似功能的应用程序，但每个应用程序之间都存在一些差异。例如，一些网站具有群组创建功能，其他网站具有用户个人资料页面，还有一些网站允许用户累积成就点等。
我们的客户希望用户能够使用相同的用户名/密码登录每个应用程序，因为用户必须为每个站点注册不同的帐户实际上没有意义。
我们如何设计我们的数据库？是为所有应用程序使用一个中央数据库更好，还是将它们分成单独的数据库并跨数据库进行联接？性能方面和设计方面哪个更好？
感谢您的任何见解！
My company creates a lot of applications that have very similar functionality, with a few differences between each one. For example, some sites have a group creation feature, others have user profile pages, and yet others allow users to accumulate achievement points and such.
Our clients want users to be able to log in to each application with the same username/password, since it doesn't really make sense for the user to have to register a different account for each site.
How do we design our database? Is it better to have a single central database for all of our applications, or separate them into individual databases and do JOINs across databases? Which is better performance-wise and design-wise?
Thanks for any insight!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
只需使用 OpenID 即可。最简单的方法是使用 Facebook Connect 作为提供商。它们使您可以获取所有用户的数据（例如姓名等），以便您可以在需要时识别它们并进行数据挖掘。
如果您不想依赖外部提供商来处理您的用户帐户，请成为您自己的 OpenID 提供商。
Just go with OpenID. Simplest to just use Facebook Connect as a provider. They let you get to all of your user's data (like name etc.) so you can identify and data mine them if need be.
If you don't want to rely on an external provider to handle your user accounts, then become your own OpenID provider.
我将有一个中央服务器，它托管一个用户数据库和用于访问该用户数据库的 Web 服务。
这样您就可以使用相同的数据库，并从前端通过 Web 服务登录到该系统。
这也是可扩展的，并且会随着应用程序的复杂性而增加。
I would have a central server, which hosts a user db and web services to access that user db.
That way you can use the same DB, and perform logins over web services to that system from your front end.
This is also scalable and can grow in complexity with your applications.
我会采用其他两个答案并将它们组合起来形成 私有 OpenId 提供商。
这样，您就可以使用标准 OpenId 客户端进行开发，甚至可以在开发需要时向外部 OpenId 提供商开放您的应用程序。
这为组织内的其他应用程序提供了可扩展性和开放标准，以使用同一提供商。
I would take the other two answers and combines them to make a private OpenId Provider.
This way you can use the standard OpenId clients for your developments, and possibly even open your applications up for external OpenId providers if you developments need them.
This gives scalability and open standards for other applications within the organisations to use the same provider.
一般来说，我会开发主数据的表格，它们将是单一版本的真理应用广泛。每个应用程序都将访问相同的“客户群”。在您的情况下，主数据的概念似乎可以应用于您的应用程序数据库。
In a general way I would develop tables that would be Master Data, they will be single version of the truth application wide. Each and every application will access the same "clients base". In your case it seems that the concept of Master Data can be applied to your applications database.
如果应用程序托管在公司内部，您可以使用活动目录。
您可以使用 ldap 功能从 php 访问活动目录。然后，您可以将用户添加到 Active Directory 中的组，以便他们能够访问应用程序中的各种功能。
If the applications are hosted within the company you can use active directory.
You can access active directory from php with the ldap functionality. You can than add users to groups in active directory to give them access to various functionality within the application.