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.
Related
We are putting together a set of standards for our database. I am worried that down the road people will forget the standards or new developers will come online and not bother to use them.
I am wondering if there is a tool to audit standards and provide a report based on the standards. I would like it to include things like naming conventions for columns to not having GUIDS as the primary key.
Apex SQL used to have a tool like this called Enforce. But they discontinued it. Is there any such tool still on the market?
You can do a lot of things like this with Policy-Based Management. For example, here are a few tips I wrote for mssqltips that describe how to do a couple of things:
Enforce database naming conventions
Identify SQL Servers with inefficient power plans
Find unused indexes
Find all columns of a specific data type
Some various tips by other authors as well:
SQL Server Policy Based Management Tips
The sky's the limit, really. Anything you can run a SQL query to get a scalar result (and several other things as well), you can check with PBM.
For object-level stuff, you can get a good part of the way there using simple DDL triggers. For these you can simply hook onto DDL events (e.g. CREATE TABLE) and roll back if your naming conventions or other criteria are not being upheld. They work very similar to a DML trigger for modifying data in a table.
Just keep in mind that you can't always enforce everything, for example you can't rollback things that aren't "transactionable" (such as CREATE DATABASE) using either PBM or DDL triggers. And be careful where you put your "on change prevent" type of enforcement - for example rolling back a CREATE INDEX that took 12 hours isn't going to go over very well if it was rolled back only because it wasn't named correctly.
SSW of Australia also has a really nice tool for this called SQL Auditor.
They check SQL Server databases against a whole slew of "best practice" rules and give you a report on how you do according to their ruleset.
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 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.
Our client wants to support both SQL Server and Oracle in the next project. Our experience comes from .NET/SQL Server platform. We will hire an Oracle developer, but our concern is with the DataAccess code. Will NHibernate make the DB Engine transparent for us? I don't think so, but i would like to hear from developers who have faced similar situations.
I know this question is a little vague, because i don't have Oracle experience, so i don't know what issues we will find.
You can easily use NHibernate to make your application database-agnostic by following some basic practices:
Design your object model first.
Do not use any database-specific code. You need somebody with good C# experience, not an Oracle developer. Do not rely on stuff like triggers, stored procedures, etc.
Let NHibernate generate the DB schemas at least initially (you can tweak things like indexes later) It will choose the best available datatypes for each DB.
Use a DB-agnostic POID generator (hilo or guid) instead of sequences or identity.
Try to avoid using SQL. HQL and Linq work fine in 99% of the cases.
Avoid NH features that are not supported by all of your target DB (for example, Future, MultiCriteria, etc)
NHibernate has a great community. You can always ask your questions in http://groups.google.com/group/nhusers besides posting here.
There are three things to consider - the ISession object, the SQL queries that are generated and your plain-old-clr-objects that are mapped to tables.
NHiberante will generate the required SQL queries based upon the chosen database dialect. If you configure NHibernate to use the SQL Server dialect it will generate SQL server correct SQL statements. This can easily be configured dynamically at runtime based on configuration.
You also need to configure your session to connect to the right type of database. Again, various configuration methods can support dynamic ISession creation at runtime.
Your actual data objects which are mapped to tables should not need to change based on database choice. One of NHibernates strengths is flexibility it provides in supporting multiple databases via a (fairly) simply configuration change and some up-front architectural thought.
See http://codebetter.com/blogs/karlseguin/archive/2009/03/30/using-nhibernate-with-multiple-databases.aspx for some examples of how you might abstract the underlying database away from the creation and usage of NHibernate.
How do you track/manage your stored procedures, views, and functions in SQL Server?
I'd like to use Subversion, but it looks like I would have to just save & commit the CREATE/ALTER statements. That might work okay for me, but I suspect I'd end up doing a lot of nagging.
Is anyone using versioning with their databases? Is there a better way?
In the past, people have just commented out parts of the code and left it in. Or, they add little "added on 2/31/2010" comments all over. It drives me nuts, because I know there is a better way.
We do log changes in the object's header, but that's pretty limited. It would make my life easier to be able to diff versions.
Additional Info
We are using SQL Server 2005. I have Subversion (via VisualSVN Server) and TortoiseSVN installed, but I'm open to other suggestions.
By database objects, I specifically mean stored procedures, views, and functions.
There are only a few tables I would need to track. The database is the backend for a commercial application, and we mostly pull information out for reporting
I found a related question about stored procedure versioning
We script everything and put it into Subversion. Nothing can be loaded to Prod without a script (developers do not have rights to prod) and the people with rights on prod only accept scripts they loaded from Subversion.
We revision our database, schema creation, dw, etl, stored procedures just like any other piece of code, because it's code!
I have also seen people type dates in headers, etc. This is normally due to them completely missing the point of revision control.
Have a look at liquibase, here
It manages your sql changes/scripts for you, and can apply them in conjunction with svn via hooks or scripts. Makes doing all sorts of setup easy, and helps eliminate the case of the missing trigger/sproc/etc...
I'm not sure what you all mean with "database objects". Are these only the tables, views, procedures etc or also data? I mean daily created data?
Assumed you mean the database schema definition. By my experience there is only one way to handle database schema definitions (if you don't have NHibernate or some similar tool). You write sql scripts that create your database from scratch and check them in. You use the same scripts for installation of your software. You see the differences by just comparing the scripts files.
Whenever I've gone through this excercise, it's come down to 3 main things that need to be source-controlled:
Stored Procedures / Views / Triggers (more or less anything that can be fairly expressed as "code". These are fairly simple, include a conditional drop and create at the top of the file.
Table Schema - DROP / CREATE statements as above. You can try to get fancy with ALTER statements, but it tends to get really messy.
The biggest challenge we faced was this forces you into a system where your DB goes back to an initial state often - if there's a fair amount of work involved in bringing DBs to something usable / testable, it can be a pain. In that case we kept a library of scripts that brought a DB to various usable states, and source controlled those as well.
Data within tables. We looked at a couple of approaches here - either a series of INSERT statements stored in a file like "TableName_Data.sql" or a CSV file with custom build tooling that parsed and inserted when the DB was rebuilt.
Ultimately we went with the INSERT statements for simplicity's sake.