In this day and age why are web and database separate systems?

I originally posted this as a question on the StackExchange wesbite ProWebmasters where it got put on hold for the legitimate reason that it wasn't an appropriate question for a Q&A website and then on Programmers where it also got put on hold for the same reason.

Any website other than a very simple one uses a database these days, right?

Well then why is there a separation between web server and database server? Surely there has to be an advantage in integrating these two systems into one?

When I develop a website, I create a database, start on my website coding, and I generally use an database object mapping tool to make my website understand my database structure. Changes in one system often mean changes in the other.

Then when my website runs, my website has to create connections to my database server to process data.

I propose that the web and database server become one!

Don't misunderstand me, I know that for reasons of performance and scalability the processing by these systems may need to be split over two or more physical servers and whatever I am suggesting would need to cater for this.

What I am suggesting is creating something like an IIS or Apache with a built-in SQL Server or MySQL.

The database structure should be created in the website coding. I don't just mean code first type database design. Changes to the database would be in the website code so would be instantaneous and wouldn't require updating models, etc.

I understand that databases are frequently used by multiple websites or other applications (desktop or mobile apps) so this would need to be catered for, maybe the database code could be some type of shared module. I haven't fully thought this part through but non websites (eg. desktop or mobile apps) could connect to the database through the website or shared module via a web API or perhaps directly, just like to a database server.

This new system would need a programming language that has database structure creation and query as an integral part of the language.

It would allow processing to be split across multiple servers.

On the StackExchange websites I tried to improve my question with an edit as it seemed many people might not have fully understand my idea...

Edit: I don't think I explained my concept very well, and I am struggling to explain it better, but here goes...

We have two different systems here, a web application which is developed in a programming language and is accessible via web server software (not interested in the hardware for the sake of hopefully better explanation). Then we have a database file/s which is accessible via database server software. When the web server needs to access data a connection is made between two systems and communication and translation between these two systems occurs so that data can be moved back and forth.

My suggestion is that the web server software could include the functionality of the database server software. I'm not talking about evolving and combining what we already have but something more revolutionary. And in addition to the server software, a programming language that has database access at its core rather than an add-on.

I'm a Microsoft developer and have dabbled a bit in other environments but I haven't found one where database access is as good as it could be. In Microsoft-land we either write our SQL queries and send them from our application to database server, or maybe use stored procedures, or maybe use a database object mapper, and possibly Linq which then has to be translated into SQL by the web server. We generally like to have things strongly typed. Then maybe when something changes in the database we have to update our models, etc, etc. It works but it doesn't seem ideal to me, and I think that somehow this needs to be better integrated.

And I'm not suggesting that this combined system shouldn't run on more than one physical server, and I'm sure that would be a necessity. However, I haven't given much thought to how that might work. That's a problem for later (if ever).

Or just maybe everyone understood perfectly and it's just a crap idea.

Although this idea was almost universally shot down by StackExchange members, I still think there's some merit to it, and I need to think it through more, and explain it better.

After a little thought, and people's suggestion to explain it as a solution to a problem, here is revision 3...

There are two problems I want to solve.

Number one is that because there is a separation between web server and database server that there is a loss of some efficiency and performance.

Number two is that when developing code, because of the separation between the application and the database, we either have to do away with strongly typed code, or maintain the database structure in two systems. Strongly typed code is essential for efficient development, but it is not efficient to have to maintain the same structure in two different systems.

My solution to problem number one is two combine the web server and database server applications into one. I don't mean on one piece of hardware, and I haven't considered how this could be split over multiple server hardware. But why does a web server need to connect to a database server, when it could also be the database server?

For a solution to problem number two, I propose a programming language and development environment that better integrates with databases.

If these two systems were better integrated, when I write a database query it would be strongly typed against the actual database structure, rather than a model.

Forget what I said about code first database design - it doesn't matter how the database is created, more that it is more integrated and there is nothing in the middle to slow down development.

The programming language would have more integrated database query and manipulation. I think Linq to SQL is on the right track for this, but would need to be closer aligned to T-SQL to avoid some of the work-arounds we have to do now. We should be able to do an outer join in less code, and we should be able to select columns from different tables without having to create a specific model, anonymous type, or a database view.

I know I'll cop more flack about some of these points but I encourage you to think outside of the way we do things now, a lot of which is because there is such separation between these two systems which are almost exclusively used together.

And maybe what I am talking about is more evolutionary rather than revolutionary after all.