更新2010-11-25
传统的独立应用程序（A1）正在重新创建为Web应用程序（A2）。
A1是用Delphi 7编写的，它使用MS Access数据库来存储数据。 A1已经分发给~1000个活跃用户，我们在A2的构建过程中无法控制。
数据库有~50个表，一些包含用户数据，一些包含模板数据（不需要复制）;这些用户表中有3-4个较大（<5000个记录），其余用户表较小（<100）。
一旦A2'实时'，A1的用户应该能够迁移到A2。我正在寻找方案的比较。
一种选择是为这些用户开发一个独立的“更新”工具，并让此更新工具通过Web服务与A2数据库通信。
另一种选择是允许用户将他们的Access数据库（~15 MB）数据库上传到我们的服务器，运行某种SSIS包（可能是一夜之间），将其转换为该用户的A2，然后删除Access数据库
我错过了选项吗？哪个选项是“最好的”（我知道这可能有点主观，但希望情景的专业和缺点至少可以明确）。
如果需要，我很乐意将其作为社区维基。
更新2010-11-23：有人建议方案1的变体是让更新工具/应用程序直接与生产数据库对话。这可行吗？
更新2011-11：到目前为止，这已经投入生产。用户上传.mdb所在的.zip文件，该文件已解压缩并放置在安全位置。每晚进行一次SSIS预定作业并将数据移动到临时表，然后通过SP将其转移到生产中。
答案 0 :(得分：2)
由于新的数据库服务器很可能是业界的标准数据库引擎，为什么不考虑将访问应用程序链接到此数据库服务器？这样你就可以简单地将数据发送到sql server。
我不确定为什么在访问支持到该数据库引擎的ODBC链接时，甚至建议使用一组Web服务到数据库引擎。因此，一个可能的升级路径是简单地在访问中发布一个新应用程序，该应用程序必须放在与其当前现有数据文件（和应用程序）现在相同的目录中。然后在启动时，这个应用程序可以简单地将其所有表链接到现有数据库，另外还有一组表链接到数据库服务器。这在构建某种类型的Web服务方法方面要少得多。我想这部分内容围绕着托管数据库服务器的位置，但在大多数情况下，也许在迁移期间，您可以在每个人都可以访问它的地方运行数据库服务器。许多网络提供商现在允许外部链接到他们的数据库。
还不清楚在数据库服务器系统上，您将为每个数据库创建单独的数据库，或者如您在标题中所建议的那样，它们将全部放入一个数据库中。由于将要放置在一个数据库中，因此在升迁期间，将在此升迁过程中添加标识用户位置或计划区分每个数据库的附加列，以区分每个用户数据集。
此类迁移的容易程度取决于开发人员用于新系统的架构和数据库布局。希望并且显然它有针对每个用户或位置的规定，或者您计划区分系统的每个用户。因此，我不建议使用Web服务，但建议将Access应用程序中的表连接到SQL Server实例（或您运行的任何服务器）。
答案 1 :(得分：2)
如何最好地执行此操作取决于必须强制执行的参照完整性和业务规则（如果有）。例如，合并数据库时是否存在重复的可能性？我知道他们正在从你有点神秘的声明中合并：“是的，所有的数据库，用户ID的aspnet成员资格”。
答案 2 :(得分：2)
我倾向于上传完整的数据库并在服务器上运行转换。
在任何一种情况下，您都需要编写转换程序。真正的问题是您在客户的计算机上部署和运行的转换量。我会尽可能简单地保持这一部分，即只是上传。这样，如果您在转换过程中发现任何错误或意外数据，您只需更新服务器即可，无需重新部署转换程序。
您所谈论的数据总量不会太大而无法上传，而且听起来大多数数据都需要在任何情况下上传。
如果您在本地安装转换程序，则需要一种从中途停止的转换中恢复的方法。这可能比简单地重新启动访问数据库的上传要复杂得多。
此外，您并未表明转换完成后是否需要Web服务。将这些服务放在一起并在转换过程中保持运行和安全的努力将远远超过简单的上传应用程序或Web表单。
另一个因素是您的客户转换速度有多快。如果其中一些将运行当前应用程序一段时间，您可能需要更新转换应用程序，因为服务器数据库会随着时间的推移而更改。如果您上载数据库并在服务器上运行转换，则只需要更新服务器转换程序。客户下载转换程序没有任何风险，但在服务器数据库更新之后才会运行它。
我们有类似的情况，我们选择在服务器上运行转换。我们为用户构建了一个上传文件的网页。在这种情况下，没有什么可以为新应用程序部署。我们发现的唯一缺点是让用户选择正确的文件。如果您使用Web表单进行上载，则由于安全限制，您无法为用户预先选择文件名。在我们的例子中，我们知道文件的位置，但客户没有。我们在上传页面上提供了用户帮助他们的说明。您可以通过编写一个小型桌面应用程序来为用户执行上载来避免这种情况。
我看到编写基于服务器的转换的唯一缺点是，您的一些模板数据将被上传，这是不需要的。无论如何，这只是少量数据。
服务器优点： - 由于错误，意外数据或服务器数据库的更改，无需重新部署转换 - 更容易保护（可能），只有一个接入点 - 上传。当然，您接受访问数据库形式的客户数据，因此您仍然不能信任其中的任何内容。
服务器缺点： - 上传不需要的模板数据
桌面优势： - ？我在遇到任何
时遇到了麻烦桌面缺点： - 可能需要部署多个版本
直接与服务器数据库通信。我有一个应用程序直接与托管数据库对话，以避免创建Web服务。它工作正常，但如果有机会我不会再采取这条路线。互联网定期丢弃，SQL提供商无法恢复得很好。我们培训了我们的客户，只是在发生这种情况时再试一次。我们这样做是为了避免为我们的桌面应用程序创建Web服务。我们只引用服务器连接字符串中的IP地址。有一整套安全理由不采取这种方式 - 我们对安全设置和可能的风险感到满意。最后，使用桌面应用程序而不做任何修改的权衡并不值得拥有不稳定的产品。
答案 3 :(得分：2)
如果您无法控制A1的1000多名用户，您将如何将他们全部转换为A2？
您是否考虑过为他们提供一个SQL Server Express数据库进行升级，并让他们在自己的服务器上托管Web应用程序？