Question

Instead create only stored procedures and call them from from the code?

Answer 1

There is a place for dynamic SQL and/or ad hoc SQL, but it needs to be justified based on the particular usage needs.

Stored procedures are by far a best practice for almost all situations and should be strongly considered first.

This issue is a little bigger than just procs or ad hoc, because the database has a wide variety of tools to define its interface, including tables, views, functions and procedures.

People here have mentioned the execution plans and parameterization but, by far, the most important thing in my mind is that any technique which relies on exposed base tables to users means that you lose any ability for the database to change its underlying implementation or control security vertically or horizontally. At the very least, I would expose only views to a typical application/user/role.

In a scenario where the application or user’s account only has access to EXEC SPs, then there is no possibility of that account being able to even have a hope of using a SQL injection of the form: “; SELECT name, password from USERS;” or “; DELETE FROM USERS;” or “; DROP TABLE USERS;” because the account doesn’t have anything but EXEC (and certainly no DDL). You can control column visibility at the SP level and not have to deny select on an employee salary column, for example.

In other words, unless you are comfortable granting db_datareader to public (because that’s effectively what you are doing when you LINQ-to-tables), then you need some sort of realistic security in your application, and SPs are the only way to go, with LINQ-to-views possibly being acceptable.