In short - is it a good design solution to implement most of the business logic in CLR stored procedures?
I have read much about them recently but I can't figure out when they should be used, what are the best practices, are they good enough or not.
For example, my business application needs to
- parse a large fixed-length text file,
- extract some numbers from each line in the file,
- according to these numbers apply some complex business rules (involving regex matching, pattern matching against data from many tables in the database and such),
- and as a result of this calculation update records in the database.
There is also a GUI for the user to select the file, view the results, etc.
This application seems to be a good candidate to implement the classic 3-tier architecture: the Data Layer, the Logic Layer, and the GUI layer.
- The Data Layer would access the database
- The Logic Layer would run as a WCF service and implement the business rules, interacting with the Data Layer
- The GUI Layer would be a means of communication between the Logic Layer and the User.
Now, thinking of this design, I can see that most of the business rules may be implemented in a SQL CLR and stored in SQL Server. I might store all my raw data in the database, run the processing there, and get the results. I see some advantages and disadvantages of this solution:
Pros:
- The business logic runs close to the data, meaning less network traffic.
- Process all data at once, possibly utilizing parallelizm and optimal execution plan.
Cons:
- Scattering of the business logic: some part is here, some part is there.
- Questionable design solution, may encounter unknown problems.
- Difficult to implement a progress indicator for the processing task.
I would like to hear all your opinions about SQL CLR. Does anybody use it in production? Are there any problems with such design? Is it a good thing?