Question

我们正在使用Visual Studio 2010，但这首先是用VS2003构思的。

我会向团队提出最好的建议。目前的设置几乎让我呕吐。它是一个C＃解决方案，大多数项目都包含.sql文件。因为我们支持微软，甲骨文和Sybase，所以自制一个预处理器，就像C预处理器一样，除了替换是由家庭酿造的C＃程序执行而不使用yacc和类似的工具。 #ifdefs用于条件宏定义，是的 - 宏是这样做的方式。一个宏可以扩展到另一个或两个宏，但最终应该终止。只有宏中包含#ifdef - 其余类似SQL的代码才使用这些宏。

现在，各种配置：Debug, MNDebug, MNRelease, Release, SQL_APPLY_ALL, SQL_APPLY_MSFT, SQL_APPLY_ORACLE, SQL_APPLY_SYBASE, SQL_BUILD_OUTPUT_ALL, SQL_COMPILE，以及另外两个。

另外：Any CPU, Mixed Platforms, Win32。

让我疯狂的是必须正确配置它，以及从12 x 3 = 36配置中选择正确的配置，以及必须根据数据库的类型替换数据库名称：config，main或gateway。我认为配置应该简化为Debug，Release和SQL_APPLY。另外，使用0,1和2似乎是80年代...... 最后，我认为我打算为3种类型的供应商构建或不构建3种类型的数据库应该只配置一个tic tac toe board，如：

XOX
OOX
XXX

在这种情况下，它意味着构建MSFT + CONFIG，所有SYBASE和所有GATEWAY。

尽管如此，使用文本文件和预处理器以及许多配置的整体情况似乎令人难以置信的笨重。现在是2010年，那里的人肯定会有一个非常干净和/或创造性的工具/解决方案。唯一的专家是现有的宏集合已经过充分测试。

您是否曾经编写过适用于多家供应商的SQL？你是怎么做到的？

SqlVars.txt（30个用户中的每一个都制作模板的副本并修改它以满足他们的需要）：

// This is the default parameters file and should not be changed.
// You can overwrite any of these parameters by copying the appropriate
// section to override into SqlVars.txt and providing your own information.

//Build types are 0-Config, 1-Main, 2-Gateway
BUILD_TYPE=1

REMOVE_COMMENTS=1

// Login information used when applying to a Microsoft SQL server database
SQL_APPLY_MSFT_version=SQL2005
SQL_APPLY_MSFT_database=msftdb
SQL_APPLY_MSFT_server=ABC
SQL_APPLY_MSFT_user=msftusr
SQL_APPLY_MSFT_password=msftpwd

// Login information used when applying to an Oracle database
SQL_APPLY_ORACLE_version=ORACLE10g
SQL_APPLY_ORACLE_server=oradb
SQL_APPLY_ORACLE_user=orausr
SQL_APPLY_ORACLE_password=orapwd

// Login information used when applying to a Sybase database
SQL_APPLY_SYBASE_version=SYBASE125
SQL_APPLY_SYBASE_database=sybdb
SQL_APPLY_SYBASE_server=sybdb
SQL_APPLY_SYBASE_user=sybusr
SQL_APPLY_SYBASE_password=sybpwd

... (THIS GOES ON)

Answer 1

您是否曾经编写过适用于多家供应商的SQL？你是怎么做到的？

我使用了ORM's。检查NHibernate。由于您使用的是VS2010，您还可以查看MS ADO.Net Entity Framework ORM使您能够高度抽象数据库。仍然会分别为每个RDBMS手工制作查询，但根据我的经验，它不到10％。

对于其他商业和开源ORM，请查看维基百科文章：List of object-relational mapping software。

编辑：重新交易平台评论：

我从未参与过这样的项目，所以我真的无法给出任何有意义的建议。作为一般建议，ORM可以帮助您整合数据访问层并最大限度地减少对RDBMS特定代码的需求。大多数ORM也可以自动生成数据库。

对我来说，这是不可能的性能损失。您应该使用顶级ORM进行一些测试，包括商业和开源，然后决定（微软可能有兴趣与在您的市场中使用Entity Framework的公司合作）。

另外，不要忘记，在现有产品中引入ORM很难，所以这是您需要考虑的另一个问题。

Answer 2

你有没有必要写SQL 适用于几家供应商？怎么样你做到了吗？

从根本上说，您可以通过在数据层和任何其他层之间添加一层抽象来实现。然后你有几个选择：

使用智能ORM构建数据库特性的数据层和帐户
使用提供者模型创建数据层，您可以在其中为每个将受支持的数据库系统创建库，并使用从配置文件中读取内容的代码来确定要加载的提供程序。

听起来你的情况中的根本问题是数据层没有封装到单个库中，而是完全屏蔽了任何其他层。如果这是真的，松散的凝聚力和紧密耦合是你的困境的一些来源。

您应该考虑重构当前的库，以便所有数据库交互都在单个库中完成，并通过接口从上面的任何层完全抽象出来。这可以通过多个发布周期逐步完成，直到最终所有调用都通过一个与数据库无关的接口或抽象类，其中您有工厂方法为相关数据库加载适当的具体类。

欲了解更多信息：

建议一种组织/构建数据库解决方案的替代方法

2 个答案: