A
Andy B
Where would probably be the best place for queries to the database? in the
db as stroed procs or in the dataSet.
db as stroed procs or in the dataSet.
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
The dataset is the result of a query to the DB
Maybe what you meant is a SP vs a query. Personally I prefer using SP. but
sometimes is easier to build the query, especially if you need some complex
combination of where/sort by clauses
The dataset is the result of a query to the DB
Maybe what you meant is a SP vs a query. Personally I prefer using SP. but
sometimes is easier to build the query, especially if you need some complex
combination of where/sort by clauses
N
Nicholas Paldino [.NET/C# MVP]
Andy,
Personally, I prefer them in the database, as it makes them more
managable. Also, it provides an API layer in case you have to do
multiple-query work in the stored procedure to produce the output for your
query (as opposed to a single query that you are sending).
Personally, I prefer them in the database, as it makes them more
managable. Also, it provides an API layer in case you have to do
multiple-query work in the stored procedure to produce the output for your
query (as opposed to a single query that you are sending).
C
Cowboy \(Gregory A. Beamer\)
The TableAdapters are nice (ie, in the DataSet), but far more useful when
you can separate out the definition from the data access, which requires
..NET Framework 3.5/Visual Studio 2008. I generall do not head this
direction, but I am not against it, as it performs rather nicely.
If you go the database route, I would code as stored procedures. I know
there are others who will disagree with me on this, but it is easier, esp.
when learning, to secure sprocs than it is to secure code in objects served
up by a factory method, etc.
The stored procedure also acts as an abstraction as long as you are using a
relational server that allows sprocs, as you can change the driver/provider
and still query. This is not always true in practice, although it is in
theory (Oracle, for example, requires passing in a structure for output when
using the OracleClient objects).
One thing the abstraction does allow, however, is altering schema underneath
the sprocs, so you can version your database without impacting application
logic.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box!
|
*************************************************
you can separate out the definition from the data access, which requires
..NET Framework 3.5/Visual Studio 2008. I generall do not head this
direction, but I am not against it, as it performs rather nicely.
If you go the database route, I would code as stored procedures. I know
there are others who will disagree with me on this, but it is easier, esp.
when learning, to secure sprocs than it is to secure code in objects served
up by a factory method, etc.
The stored procedure also acts as an abstraction as long as you are using a
relational server that allows sprocs, as you can change the driver/provider
and still query. This is not always true in practice, although it is in
theory (Oracle, for example, requires passing in a structure for output when
using the OracleClient objects).
One thing the abstraction does allow, however, is altering schema underneath
the sprocs, so you can version your database without impacting application
logic.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box!
|
*************************************************
P
Peter Bromberg [C# MVP]
I agree with Gregory, although this all smacks of the "Stored Procedures are
Evil" debate. Stored procs are not evil.
--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com
Evil" debate. Stored procs are not evil.
--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com