I am looking to insert and update records in a database using functions and logic that are not available in SQL Server or any other RDBMS for that matter. After Googling around a bit this morning, I have come across the concept of Extended Stored Procedures. As far as I can tell, I should be able to compile my desired functionality into a dll, make a stored proc utilizing that dll to do the inserting/updating.
However, most of the articles and examples I have come across are somewhat dated (~2000). Are extended stored procedures still an acceptable practice? I am far from an expert in this area, so any other suggestions or comments would be greatly appreciated.
If you're using SQL Server 2005 or later, SQL CLR is the area to look at. You can call .NET code from within SQL Server.
This article on MSDN is a good place to start.
Are extended stored procedures still
an acceptable practice?
No, they are officialy deprecated and will be dicontinued in a future release. See Deprecated Database Engine Features in SQL Server 2008 , in the Features Not Supported in a Future Version of SQL Server table:
Extended stored procedure programming: Use CLR Integration instead.
I usually recommend against using CLR procedures, in most cases you can refactor the problem you are facing, into something that Transact Sql can handle.
Of most concern is the procedural approach that often accompanies the use of CLR procedures, when a relation database performs best when performing set based operations.
So the first question I always ask, is there anyway to refactor the problem into a set based operation.
If not, then I ask why would you want to execute the code inside of the database server, instead of in an application layer? Think about the performance impact you might have by placing the logic inside the database. (This might not be an issue if your db server has plenty of extra processing time).
If you do go head with CLR procedures, I think they are best applied to intensive calculations and complex logic.
Related
Are there any libraries, open source or otherwise, that can be installed into a SQL Server instance (2008 or later) that can enforce AOP standards? I'd really like to avoid enforcing cross-cutting concerns with templates across our development staff. AOP seems like the best option, if it's available.
If it doesn't exist already, I'll try to roll my own.
EDIT:
Some examples might be subclassing Table to make specific kinds of tables, like mixin characteristics. I'm in a data warehouse environment with a lot of audit requirements so we create bitemporal tables a lot. It would be awesome to have a
CREATE BITEMPORAL TABLE
statement that would add transaction and valid time and modify CRUD statements against those tables. (Yes, I know that views and triggers can do this, somewhat.) A harder thing to accomplish would be stored procedures with specific logging or transaction characteristics, like
CREATE PROC FOO /* VERBOSE, ATOMIC, SERIALIZABLE */
and have the body automatically wrapped with the appropriate T-SQL to do those things. Yes, it's possible to add stored procedures to take those arguments and do SQL generation and compile those artifacts. But the drawback is that there's no enforcement - a developer may bypass the procedure and use CREATE PROC directly - and that the content in syscomments is the generated code, not the AOP annotated version, which breaks the abstraction.
Maybe you are interested in having a look at AO4SQL - a programming language that brings AO concepts to SQL. Conceptually, the tool works with any SQL server.
You can download my paper "AO4SQL: Towards an Aspect-Oriented Extension for SQL" that was published at the RAM-SE 2011: http://www-users.cs.york.ac.uk/~manuel/Events/RAM-SE11/RAMSE11papers.zip
Keep in mind that AO4SQL is a prototype tool, but if you would likt to join an open source project ... get in contact with me.
Interesting. I've never even thought about applying AOP techniques to a SQL Server.
With SQL Server 2008, I believe you have the ability to call .NET code, so you could maybe work in a standard AOP tool like PostSharp or Castle DynamicProxy that way.
This seems to be a duplicate of the other question with the same title, but it actually isn't.
We have our business logic implemented mostly as DB2 stored procedures (I see that H2 has a DB2-compatibility mode - nice!).
How can we use H2 for in-memory unit testing with these procedures?
Unfortunately H2 seems to lack the CREATE PROCEDURE command from its grammar.
I don't want to use Java functions as stored procedures. It would be best if the very same sql files could be used for testing and production as well... am I asking too much?
EDIT: we also use SQL cursors... again, no sign of support :-(
Unfortunately, the compatibility mode doesn't go as far as supporting SQL prodecures. Currently, the only solution is to use Java functions. SQL cursors are also not supported, sorry. But I will add these feature requests to the roadmap. Patches are welcome of course :-)
I'm working on a database heavy project, where the Microsoft SQL databases are very mature (16 or more years-old mature), and an old product uses VB6 and ADO to generate sql which interacts with the database. I've been given the task of porting/re-writing the ancient version with a new .NET version.
I'd love to use LINQ-to-* to ensure easy maintainability, but having tried for the last several weeks I feel like LINQ-to-SQL isn't flexible enough, LINQ-to-Entities has too much overhead, and LINQ-to-Datasets is pointless since I would be just as happy using Ado.Net.
The program operates on two databases at once: one is a database with a very consistent schema containing meta-data, and the other a database which has a varying schema, is tightly coupled to the meta-database, and dictates what information from the meta-database you are interested in at any given time. Furthermore, I need non-LINQ information from both databases (such as system-stored procedures, and system-tables).
Is there any way to use LINQ intelligently here? I'd love the static typing, but if I can't have it I don't want to force my square app into a round framework.
Just an FYI, you can get access system tables (and sys stored procs too?) using LINQ. Here is how:
Create a connection to the server you want.
Right-click the server and choose Change View > Object Type.
You should now see System Tables and User Tables. You should see sysjobs there, and you can easily drag it onto a .dbml surface.
Above was stolen from this post.
The best answer seems to be to use ADO.NET completely. I have the option of using Linq-to-Sql over the metabase and ADO.NET for any other database access, but that would make the code feel too inconsistent for me.
I am developing a data driven website and quite a lot of programming logic resides in database stored procedures and database functions. I found myself changing the stored proc/functions quite a lot in order to fix bugs or add new functionality. The data (tables) have remained mostly untouched.
The issue I am having is keeping track of versions of stored proc/functions. Currently I am incrementing version of whole database when I do a set of changes. As data is huge (10 Gb) I get issues having to run development version and release versions of databases in parallel.
I wish to put all the stored procs and functions in one database and keep data in one database, so that I can better manage the changes.
I am sure others would have encountered similar suggest and request suggestions on how to best handle this situation.
I would also recommend using source control keyword expansion in your stored procedures ($Version:$)
That way you can eyeball, grep, search syscomments, etc to see what version you have on your deployed database.
You can version just the schema dumps. In combination with source control keword expansion (as suggested by Rawheiser), you just take a look at what version you have in the database, generate a diff and apply it.
Also, there are several excellent tools to compare databases and their schemas, generate DDL scripts etc.: SQL Workbench, Power Architect, DDLUtils and Redgate SQL Compare, to name a few. SQL Compare is likely to work best with SQL Server, although all the others are FOSS and provide a higher ROI (in terms of time spent learning and what you can do with them) as they are platoform and RDBMS independent.
Finally, I have to say...I understand that the immediate results you get with logic in the DB are tempting, but if you've gone beyond more than a couple of procedures in the database, you're setting your self up for quite a lot of pain, sifting through what easily turns into spaghetti code and locking your application to a single database vendor. You might have your reasons, but I've been there and didn't like it very much. Logic can live very nicely in a different layer.
For source control you have several options:
Use a Visual Studio Database project.
Use SQL Server 2005's built-in support for source control
Use a third part tool such as SQL Compare
IMO Option 1. is preferable.
I have a SQL Server stored procedure which has been in use for years. This stored procedure calls lots of other procedures. I would like to extract each inside procedure one at a time and implement its business logic to a .NET Class project.
In order to do that, I have to call .NET assembly from parent stored procedure and the returned result will be used by parent procedure. Since SQL Server 2005 and higher has CLR integration, so I think, executing .NET assembly inside stored procedure [or any Database objects] should not be a big deal, can you please point me some references where i can find examples or article to implement it?
Thank you very much for your help .
I really feel that this would be an inappropriate use of SQL CLR. The purpose of CLR integration is to support complex data types and operations that are normally very hard to do in pure SQL (such as sequences, regular expressions, hierarchy, geospatial, etc.) Not to implement a domain model in your database.
Domain models and business logic are separate from relational/data models. They should be in a proper business tier of some sort. Don't hack them into a database using the CLR.
(Note: I use SQLCLR a fair bit. I am not railing on CLR integration. I just don't think that this question reflects a wise design decision.)
MSDN
Building my First SQL Server 2005 CLR
An Intro to CLR Integration in SQL Server 2005
For loads more ;)
I think you should use SQL Server Integration Services (SSIS). As far as I understand, it solves this case, to orchestrate the procedure calls and gives you much more too..
I'm not too sure if moving this decision outside the db layer is a good decision.
Hope it helps..