Further refining the Web+DB concept

I'm not ready to give up on this concept. Although I should change the name to app+db.

Here's the summary of issues I'm wanting to solve or improve:

1. My database is stored in the file system. My application running on an application server connects to the database server application which reads and writes these files.
2. My application only knows what I tell it about my database structure.
3. I want my database querying and manipulation to be strongly typed so I use Linq to construct queries (and other reasons), but I need to know Linq well to ensure my queries are efficient. I also need to know T-SQL well to ensure that the Linq translations are efficient.

Number 1 is not a big issue, but given that probably 99% of applications require a database I feel that there would be benefits in combining the application and database server applications.

Number 2 has kind of been solved with code first database creation. My thoughts are that the code should define the database structure so we can do away with having to keep our database and application in sync.

Number 3 is probably my biggest issue. I frequently work on older applications with SQL queries constructed as strings and it makes me appreciate what a great development environment we have in the Microsoft world with Visual Studio, and strongly-typed representations of our databases (eg. Linq to SQL).

Unfortunately, as much as I appreciate writing my database queries in Linq, it irks me that I now have to be an expert in two types of database querying. I have to know how to craft efficient Linq queries, and also know how to craft efficient T-SQL so I can trouble shoot and fine tune the queries that Linq generates.

Do we need a translator? Why can't we just write strongly typed T-SQL (or some native database language) like we do Linq?

Also, for large projects I usually break up my database into modules of related tables, with a Linq to Sql dbml file for each. But many queries need data from other modules. This means I either have to create a view (defeats the purpose of trying to keep all logic in the one place) or include the other table in multiple Linq to Sql dbml files.

Sorry to bring up early versions of dBase again, but I still see that as a good example (through rose coloured glasses): we create our applications in the database application.