T
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Marc Scheuner [MVP ADSI]
http://www.itwriting.com/blog/?postid=8
It's the old debate of whether you want to have a unified data access
methodology (which might need to make some compromises in certain
places, to accomodate all target databases), or whether you want to
have "targeted", highly sophisticated but vendor-specific acess
methods.
If you use the unified method (which MS was a big proponent of so far
- see ODBC, OleDB/ADO), you do get a certain degree of independence
from the actual database in use - you might be able to support MS SQL,
Oracle, IBM DB2, Interbase - you name it. At the same time, you're
probably also taking a bit of a performance and feature hit - some
specific features of each database might not be available to you.
So I guess it really comes down to whether you will actually need to
support multiple database backends - if so, I think Borland's BDP.NET
could be a fantastic way to go. One set of .NET components, which can
be used against any database backend (which has a BDP.NET driver, that
is). If you try to do the same with "straight" ADO.NET, you'll have to
have one version for MS SQL Server (using SqlConnection, SqlCommand
etc.), and possible a second one for Oracle (OraConnection,
OraCommand), and yet another for "generic" OleDB connections
(OleConnection, OleCommand), which will end up being rather messy to
create / maintain.
However, if you simply target just one database platform (Interbase,
or Oracle, or MS SQL Server), you're probably better off using a
dedicated .NET driver set for just that one database which offers all
the features and all the performance you can get.
It's a trade-off - you be the judge which is more important to you -
database independence or optimal feature/performance use.
Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
What do others think?
It's the old debate of whether you want to have a unified data access
methodology (which might need to make some compromises in certain
places, to accomodate all target databases), or whether you want to
have "targeted", highly sophisticated but vendor-specific acess
methods.
If you use the unified method (which MS was a big proponent of so far
- see ODBC, OleDB/ADO), you do get a certain degree of independence
from the actual database in use - you might be able to support MS SQL,
Oracle, IBM DB2, Interbase - you name it. At the same time, you're
probably also taking a bit of a performance and feature hit - some
specific features of each database might not be available to you.
So I guess it really comes down to whether you will actually need to
support multiple database backends - if so, I think Borland's BDP.NET
could be a fantastic way to go. One set of .NET components, which can
be used against any database backend (which has a BDP.NET driver, that
is). If you try to do the same with "straight" ADO.NET, you'll have to
have one version for MS SQL Server (using SqlConnection, SqlCommand
etc.), and possible a second one for Oracle (OraConnection,
OraCommand), and yet another for "generic" OleDB connections
(OleConnection, OleCommand), which will end up being rather messy to
create / maintain.
However, if you simply target just one database platform (Interbase,
or Oracle, or MS SQL Server), you're probably better off using a
dedicated .NET driver set for just that one database which offers all
the features and all the performance you can get.
It's a trade-off - you be the judge which is more important to you -
database independence or optimal feature/performance use.
Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
T
Tim Anderson
is). If you try to do the same with "straight" ADO.NET, you'll have to
have one version for MS SQL Server (using SqlConnection, SqlCommand
etc.), and possible a second one for Oracle (OraConnection,
OraCommand), and yet another for "generic" OleDB connections
(OleConnection, OleCommand), which will end up being rather messy to
create / maintain.
Not necessarily, as you can code to the interfaces (IDBCommand, IDataReader
etc). I've done this successfully to support both SQL Server and JET from a
single set of code. There are a few places where there is conditional code,
but the vast bulk of it is shared.
Tim