Jayanth_Kurup (10/2/2012)

---

faster simpler better coding relies on moving business logic to the application layer. This is proven in many SOA implementations. The DB should stick to simple crud operations. The stored procedure is already a layer of abstraction between the application and data , however in your case the data itself changes so functions and views or even normal tables need to evaluated on a case to case basis.

A table that had a id column as PK may not id a PK once a new column is added or deleted. Try putting business logic in .NEt and app layer and if that doesnt work evaluate how it can be done within a proc.

a common mistake i have seen people make is trying too hard to make the business logic generic. Its not a good idea coz the business logic is constantly changing to meet new scenarios and managing all that change within the DB is a major headache.

norbert.manyi (10/3/2012)

---

All the developers are on both SQL and .Net, so we will not have those kind of problems.
Most of my concerns are regarding keeping everything in one place, and as clean as possible.

So, at the moment, I can say I'm confused :) I am aware of the speed gained by keeping everything in optimized stored procedures, but in the same time, I would like to maintain flexibility to make changes in BL faster, and with less modifications.