Conflicts between relational databases and object-oriented development

Some time ago, I initially learned about LINQ, and I felt that it was indeed very good and powerful. As a result, LINQ to SQL has implemented object-oriented database operations, greatly improving the development efficiency. I don't need to talk about the specific advantages, I believe that I know more about my friends than I know.
Looking at the Development of. net over the past few years, in the. NET 1.1 era, the establishment of a database access layer may be like Code Similarly, create a business entity class and then wrap the business entity with generics. Therefore, in the business logic layer, you can access and operate the database through the data access layer in an object-oriented manner, this process requires a large amount of code to complete the writing of the data access layer.
Arrived. in the era of NET 2.0, it is much easier to complete the data access layer with strong dataset and objectdatasource. A lot of substantive work is actually automatically generated by the designer of Visual Studio 2005, the disadvantage is that the automatically generated code is difficult to perform cross-Table operations.
And now. net 3.5 (in.. Net 3.0). Through LINQ to SQL, we can also automatically generate relevant code and access and operate databases in a fully object-oriented manner. Cross-Table operations are also easy, the development efficiency has been greatly improved, and it can be said that it has reached the peak of data access methods.
From the evolution of the above data access technology, we can see that Microsoft is doing everything possible to target relational data queries and operations, but there is always no way to solve a substantive problem, that is, the scalability, maintainability, and flexibility of the database are still too poor. For example, if the database architecture changes during the development process, this change is disastrous for the data access layer. There is no solution, so you can only regenerate the code and recompile it, this change may also affect the business logic layer and interface layer. For example, a system that has been released is even more critical. These problems cannot be solved no matter whether it is a strong-type dataset or LINQ to SQL. Of course, the reason is not the strong-type dataset and LINQ to SQL itself. They are just a technology for accessing the database, the root cause is that databases are relational rather than object-oriented, which makes it difficult to use some object-oriented ideas (such as design patterns, the most widely used design patterns are at the business logic layer) to improve scalability, maintainability, and flexibility, everyone thinks that the advent of an object-oriented database is definitely a revolutionary achievement in today's object-oriented era, and will certainly subvert the previous development model. Imagine that with an object-oriented database, coupled with the use of a rational design model, a database that is flexible, scalable, and able to adapt to changing needs, the underlying changes do not affect the upper layer as much as possible. we can concentrate on the business logic processing in the upper layer code.
In fact, I personally think that LINQ is very close to this goal. Since Microsoft has achieved this step, why not directly develop an object-oriented database, like using LINQ to access and operate databases, instead of using it to map, convert, and isolate objects and relationships.
From the perspective of the present, the object-oriented database seems to be still in theory, and it has not appeared after so many years!