如何不依赖数据库供应商？ [英] How to do non dependence on database vendor?
问题描述
如果我想轻松交换我正在使用的数据库，那么在我的应用程序中开发该层的最佳方法是什么？
我基本上会有一个4层应用程序：
1.演示文稿
2.业务逻辑
3.包含标准SQL兼容的数据层查询
4.任何数据库
我正在寻找设计第3层的最有效方法。我不能使用存储的
程序因为那些是特定的两个特定数据库。在应用程序层中使用
查询的效率低于SP，但此时没有多少
选择。
欢迎任何关于此设计的一般评论。
谢谢，
Brett
"布雷特" < no@spam.net>在留言中写道
新闻：O0 ************** @ TK2MSFTNGP12.phx.gbl ...如果我想轻松交换我正在使用的数据库，在我的应用程序中开发该层的最佳方法是什么？
嗯，例如，你可以使用ODBC。我有一个.NET应用程序，它使用ODBC来访问SQL Server和另一个供应商的数据库。 Debug build为SQL Server语法调整了ODBC
DataAdapters和连接字符串，同时发布了另一个供应商的语法中放置的_same_ app的
版本。我这样做是因为它集成了我在开发环境中无法访问的数据库。数据库层顶部的应用程序不是更明智的。
也许这种方法不是你想要的。
当然，您可以使您的数据库层成为专门用于特定数据库供应商的组件。您可以定义一个通用接口来与它/它们进行通信
非特定于供应商。
- Alan
" Alan Pretre" <人******** @ newsgroup.nospam>在消息中写道
news：u6 ************* @ TK2MSFTNGP15.phx.gbl ..." Brett" < no@spam.net>在消息中写道
新闻：O0 ************** @ TK2MSFTNGP12.phx.gbl ...如果我想轻松交换数据库我'我正在使用，在我的应用程序中开发该层的最佳方法是什么？
嗯，例如，你可以使用ODBC。我有一个.NET应用程序使用ODBC
访问SQL Server和另一个供应商的数据库。 Debug构建调整了SQL Server语法的ODBC DataAdapters和连接字符串，同时发布了_same_ app的构建版本，其中包含其他供应商的语法。
我这样做是因为它集成了使用我在开发环境中无法访问的数据库。在数据库层顶部的应用程序是没有更好的。
也许这种方法不是你想要的。
当然，你可以做您的数据库层是专门用于特定数据库供应商的组件。您可以定义一个公共接口，用于与它/它们进行通信，而不是特定于供应商。
问题是，如果您需要对其进行任何更改例如，DB层，添加新的SP，你需要更改所有供应商特定的
组件。
Brett
" Brett" < no@spam.net>在消息中写道
新闻：ee ************** @ TK2MSFTNGP10.phx.gbl ...问题是，如果你需要对数据库层进行任何更改，例如添加新的SP，你必须对所有供应商的特定组件进行更改。
是的。在任何情况下都可以避免吗？
你的具体情况是什么？您是否需要同时与多种类型对话？
？你想在安装时安装一个单一的味道
时间吗？只关心改变要求下线？
- Alan
If I want to easily swap the database I''m using, what is the best method for
developing that tier in my application?
I''ll have basically a 4 tier app:
1. presentation
2. business logic
3. data layer containing standard SQL compliant queries
4. any database
I''m looking for the most efficient way to design tier 3. I can''t use stored
procedures because those are specific two a particular database. Using
queries in an app layer is less efficient than SPs but there isn''t much
choice at this point.
Any comments in general on this design are welcome.
Thanks,
Brett
"Brett" <no@spam.net> wrote in message
news:O0**************@TK2MSFTNGP12.phx.gbl...If I want to easily swap the database I''m using, what is the best method
for developing that tier in my application?
Well, for example, you could use ODBC. I have a .NET app that uses ODBC to
access SQL Server and another vendor''s DB. Debug builds adjust the ODBC
DataAdapters and connection string for SQL Server syntax, while release
builds of the _same_ app put in the syntax for the other vendor. I do it
this way because it integrates with databases that I don''t have access to in
the dev environment. The app on top of the DB layer is none the wiser.
Maybe that approach is not what you are looking for.
Of course, you could make your DB tier a component that is specialized for a
specific DB vendor. You could define a common interface for communicating
with it/them that is not vendor specific.
-- Alan
"Alan Pretre" <al********@newsgroup.nospam> wrote in message
news:u6*************@TK2MSFTNGP15.phx.gbl..."Brett" <no@spam.net> wrote in message
news:O0**************@TK2MSFTNGP12.phx.gbl...If I want to easily swap the database I''m using, what is the best method
for developing that tier in my application?
Well, for example, you could use ODBC. I have a .NET app that uses ODBC
to access SQL Server and another vendor''s DB. Debug builds adjust the
ODBC DataAdapters and connection string for SQL Server syntax, while
release builds of the _same_ app put in the syntax for the other vendor.
I do it this way because it integrates with databases that I don''t have
access to in the dev environment. The app on top of the DB layer is none
the wiser.
Maybe that approach is not what you are looking for.
Of course, you could make your DB tier a component that is specialized for
a specific DB vendor. You could define a common interface for
communicating with it/them that is not vendor specific.
The problem is that if you need to make any changes to the DB tier, adding
new SPs for example, you''ll have to make changes to all the vendor specific
components.
Brett
"Brett" <no@spam.net> wrote in message
news:ee**************@TK2MSFTNGP10.phx.gbl...The problem is that if you need to make any changes to the DB tier, adding
new SPs for example, you''ll have to make changes to all the vendor
specific components.
Yes. Is that avoidable in any case?
What is your specific situation? Are you needing to talk to multiple types
at the same time? Are you wanting to install a single flavor at install
time? Just concerned about changing requirements down the line?
-- Alan
这篇关于如何不依赖数据库供应商？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
