假设您构建了一个需要为多个客户提供服务的应用程序（数据永远不会在客户之间共享）并且客户数据本身是敏感的。
您将如何设计数据库以防止来自一个客户的突然（例如错误）数据对另一个客户可见？
例如我们有一个包含客户项目的项目表。现在我们可以将所有项目（所有客户的）放入该表中，或者为每个客户创建一个模式。
我喜欢架构分离的想法（因为它会完全分离数据），但我从来没有这样做过，我不确定这是否是一个好方法（例如，架构的更改需要维护所有客户方案） .
重要提示：该应用程序还包含在所有客户之间共享的主数据（例如客户帐户、设置、模板等）。所以我期望的另一个缺点是同时维护多个连接......
更新：是否可以仅自动复制架构？
【问题讨论】：
标签： database-design
要正确衡量选项，我认为您需要分析应用程序代码的质量。我为大客户构建了许多系统，这些系统可以很好地共享数据库，而我们从未担心过交叉共享数据。如果您有授权逻辑安全的高质量代码，那么我将始终使用一种模式；这样维护起来就容易多了
另一方面。如果您拼凑了没有业务对象库、没有标准和集中授权逻辑的 asp 页面；那么肯定会使用不同的数据库，每个客户都有唯一的登录名。
【讨论】：
我的建议是尽可能将每个客户的数据分开。使用 SQL Server，我会将每个客户的数据存储在单独的数据库中（您可以在 SQL Server 实例中拥有许多单独的数据库）。如果您没有该选项，架构可以执行非常相似的操作。
【讨论】：
您可以改为创建一个主表并为每个客户提供一个视图。然后，所有查询都将通过此视图，该视图将过滤掉相关客户之外的所有内容。
这使得维护变得容易，因为视图只定义了一个约束（对客户）并且不包含任何其他架构信息。
这是 MySQL 中的一个示例（不是最好的视图数据库，但是嘿）
CREATE VIEW projects.foocust AS SELECT * FROM projects WHERE customer = 'foocust';
【讨论】：
根据您的要求，单独的客户数据库架构听起来是个好主意。会有点头疼，但还不如打官司。
【讨论】：
我认为您将每个客户分开的想法将是最佳选择。您的主数据可以自己保存，只要客户不访问该表（或至少经常访问它）就可以了。关键在于分离所有客户的敏感数据，同意这会导致更多的工作。但是，嘿，这就是您扩展业务所获得的。
【讨论】：