选择哪种策略来构建基于 Web 的业务应用程序答案

【问题标题】：Which strategy to choose for building web based business application选择哪种策略来构建基于 Web 的业务应用程序
【发布时间】：2010-07-26 18:12:09
【问题描述】：

我打算在 asp.net mvc 中创建一个会计应用程序。
每个用户都会按月付费，我会提供每日备份等。

我不知道该选择哪种策略：

这两个选项的优缺点是什么？
如果我选择选项 2，我将不得不在代码中编写更多逻辑。我必须阻止用户看到他们不应该看到的东西（更多的数据库访问）。

最重要的两件事是：

我预计会有 20 到 30 个用户。

任何建议将不胜感激。

【问题讨论】：

【解决方案1】：

我会一如既往地选择选项 2。我来自强大的金融整合背景，所以选项 2（至少对我而言）是最好的。

在考虑使用数据时没有缺点。往返次数不会比选项 1 多。

系统的性能通常由程序员决定。如果您编写糟糕的代码，您可能会期待糟糕的性能。选项 2 提供了最简单的备份选项，因为您只需要担心 1 个数据库。如果您使用 1 个数据库，则根本不需要考虑单独的用户。

RE：用户的往返行程（或代码中的更多“逻辑”来处理），添加“Where userID = x”有多难？

无论如何，您都应该将您的 .net 代码与存储过程分开，因此从头开始编写应该不会比使用选项 1 有更多（甚至更少）往返/文件访问问题。

【讨论】：

+1 是的，在每个查询中加上一个额外的“Where userID = X”，我会减少往返。谢谢。
@šljaker 为了强制执行此操作并避免在某些查询中意外地关闭租户 ID，您可以使用内联表值函数包装您的基表，这些函数每次都需要提供租户 ID。 ITVF 的开销类似于视图（即最小），优化器可以非常轻松地使用它们。
@šljaker 用 TVF 包装每个表：CREATE FUNCTION fTABLENAME (@TenantID int) RETURNS TABLE AS RETUEN (SELECT * FROM TABLENAME WHERE TenantID = @TenantID)。然后只使用函数： SELECT * FROM fCust(@TentantID) AS c INNER JOIN Accounts(@TenantID) AS a ON a.CustID = c.CustID
我建议不要这样做，因为如果设计不当，“视图”的开销会变得很大。我们的想法是减少往返次数，但在这种情况下，您正在创建更多。如果您想让您的应用程序在不需要升级硬件或重新编程的情况下增长，只需在需要的地方添加 userID= 从一开始就“正确”地进行操作。我目前正在做一个同时拥有用户和公司（用户链接到公司）的应用程序，因为我从一开始就设计它来处理超过 1 个公司及其用户，我可以添加新公司而不想知道我的代码是否会坚持

【解决方案2】：

如果您在单个数据库中进行多租户设计，您可能实际上无法使用 SQL Server 的备份功能，因为备份单元不足以备份每个用户的数据分别。您可以使用partitions 和文件组并仅备份文件组，但分区功能并不容易管理，并且可能不适合此目的。

如果您希望为用户独立使用 SQL Server 的备份和恢复功能（这听起来像是您的评论），您可能需要将它们放在单独的数据库中。

话虽如此，我会重新考虑该要求（考虑实施选择性导出/导入），因为多租户架构总体上更容易处理。

【讨论】：

备份是我的主要问题之一 :(
@šljaker 这取决于您的备份方案是什么 - 如果它是由于作为服务提供商（您）的硬件故障而恢复数据，它可能没问题，但如果您希望用户能够备份恢复自己或能够获取该备份并在本地恢复，SQL Server 备份可能无法用于此。