Your second and third options are identical. The M in MVC is not the data model, but rather the domain model. This includes persistence, whether done directly or via an ORM, and both are perfectly correct.
The controller should manage the flow of the site and passes stuff off to the domain (sometimes via a service layer) to be handled, so persisting from there is wrong -- or at least semantically uncomfortable.
And that's why I think those tutorials simplify things to a degree that confuses the newcomer.
Try to do a little "tabula rasa" and think the process from scratch, and decoupling the concepts.
First of all, MVC is a presentation layer. It does not (or should not) even know what is backing it up. It could be a database, an xml file, a text file, an in-memory collection, whatever. It should be abstracted away.
What does MVC understand? Receives an HTTP request, parses it using the route engine, resolves to the corresponding controller/action method and does whatever you write in the action method. End of the story.
Do you ask for an id which, behind the scenes, corresponds to a database surrogate key? MVC doesn't know that. For it, it's just an int parameter of a method.
It's entirely up to you how you decouple your logic and layers, how you retrieve data and check for security.
Assume you get asked for Products/Detail/1. Is your action method under authentication (using the authorize attribute)? If so, are your products only visible to certain users?
You'll pass to a business logic method the requested id along with the username, and that method will tell you "here's your product" or "sorry, you cannot view this" based on the logic inside. And heck, if you designed it well even the business logic method won't know if behind the scenes it used a database or anything else to retrieve the product.
I hope this little explanation clarifies things a little. MVC is just about handling HTTP requests and returning a view or some json data or whatever you want to return to the users. Anything that backs it should be abstracted away and implemented as you see fit.
Best Answer
No. Your SQL files either define your Schema or they define your data access.
The data retrieved from SQL files are not your model either, or rather database record sets should not be your model. There should be a level of translation that converts your record sets into data suitable for the Model.
In an ideal scenario your Model will be agnostic of data access logic and should mereley contain data that is pertinent to one or more Views as well as view state information as well.
Your Controller should bridge the gap between the View and the data contained in the Model such that only the Controller is concerned with data access matters.
On another note, if your SQL is NOT code then what is it? You are right to store SQL in version control because they define your application as much as anything.