Should data security be performed on the database side?

Don't do that. We recently had a VERY BAD experience when the "database guru" decided to go to another company. The maintenance of all the logic in the procedures are just horrible!!

Yes, you're going to have some performance improvement, but that's not worth it. In fact, performance is not even a big concern in internal application. Invest more money in good servers. It'll pay off.

Unfortunately there is no "one true answer". The choice you must make depends on multiple factors, like:

• The familiarity of the team with the given solutions (ie if a majority of them is comfortable writing SQL, it can be in the database, however if a majority of them is more comfortable with C#, it should be in the code)
• The "political power" of each party
• etc

There is no decisive advantage in any direction (as you said performance gains are minimal), the one thing to keep in mind is the DRY (Don't Repeat Yourself) principle: don't reimplement the functionality twice (in the code and in the DB), because keeping them in synch will be a nightmare. Pick one solution and stick to it.

You could do it but its a huge pain to develop against and maintain. Take it from someone who is on a project where almost all business logic is coded in stored procedures.

For security, ASP.NET has user and role management baked into it so you might be saving trips to the database but so what? In exchange it becomes far more annoying to handle and debug system and validation errors because they have to bubble up from the database.

Unit testing is far more difficult since the frameworks available for unit testing sprocs are far less developed.

Proper oop and domain driven design is all but out the window.

And the performance gain is going to be tiny if any. We talked about this here.

I would recommend that if you want to save your sanity as a developer you fight tooth and nail to keep the database as the persistence layer only