对于跨不同应用程序的不同用途，使用单个数据库是否被认为是一种不好的做法

Question

如果您有一个大型数据库来为您的所有应用提供服务，该怎么办？因此，您需要存储客户订单的网站可以使用您的游戏用于存储注册用户的相同数据库。不同的应用程序可能只有表供他们使用。有人可能会说这可能是一个安全问题，因为如果有人破坏了您的数据库，他们可能会攻击您的所有应用程序。但是在很多数据库中，您可以使用如下所示的行来限制访问：

deny select on aTable to aUser;

我想知道这个中央数据库是否会被认为是一种糟糕的做法，如果是这样，为什么呢？

Answer 1

他们看待它，一个Web应用程序只不过是一个网页集合。因此，如果一个页面是关于烹饪，那么另一个页面是关于计算机编程的，这并不重要。

如果您也考虑过，这与我用来登录我的SO帐户的Openid非常相似！

如果您已正确实施基本安全措施，则 用户与您的网站进行互动并不重要。我将在两种情况下做出这种区分：

1. 不要将http与https混合。在共享主机上，无论如何这都不是问题;如果您购买https的证书，请按照这种方式进行操作（不包括可能影响性能的罕见情况）。
2. 应从根本上以不同的方式处理电子商务或财务数据。如果您查看典型的银行，他们会有多个登录协议，图片验证和短登录时间。这可以建立对用户证券的信心。对于游戏网站或大多数其他非关键任务应用程序而言，这将是一个痛苦。

关于结构，如果将应用程序混合到一个大型数据库中，则应考虑其他维护问题，例如：

1. 保持桌子分开;考虑每个应用程序唯一的每个表的前缀。按照上面的示例，您将使用＆＃39; ck＆＃39;启动烹饪数据库表名称，并使用＆＃39; pg＆＃39;启动计算机编程数据库表名称。如果您将来需要，这将允许您轻松分离应用程序。
2. 使用匹配表来标识哪个ID转到哪个Web应用程序。
3. 如果用户决定注册这两个应用程序，请考虑您要做什么以及如何处理它。您是否希望提供可以共享相同用户名的透明度？
4. 密切关注数据存储限制和带宽限制。
5. 如果您指望这些应用程序来增加收入，那么您将所有鸡蛋放在一个篮子里＃34;确保如果它发生故障，您可以选择还原或移动到其他主机。

这些只是需要考虑的一些事项。但从根本上说，在大型（大数据）应用程序之外，在应用程序之间共享资源/数据库/硬件没有任何问题。

Answer 2

从概念上讲，它可以完成。

实现方面，为了使各个部分彼此不同，您可以使用命名约定（根据@Sable Foste）和/或单独的数据库模式（表Finance.Users，GameApp.Users等）< / p>

管理方面，事情可能会变得棘手。重复一些观点，添加其他观点：

• 一个应用程序可能使用不成比例的大部分资源（磁盘空间，I / O，CPU）
• 跟踪版本可能很棘手（App是v4，财务是v7） - 取决于你必须支持多少个应用程序实例。
• 灾难恢复方面，一切都集中在一起。它全部作为一组备份，全部恢复为一组。财务腐败？从备份恢复...并丢失您最近的游戏数据。
• 单点故障。一个数据库关闭，所有应用程序都关闭。

这些（以及其他类似问题）是您想要考虑的权衡取舍。提前计划，以减少今天的合理和经济成为明天头痛的可能性。