Is there a programming language specifically designed for interacting with SQL databases?

The SQL queries I’ve seen almost every ORM create are highly inefficient compared to a good query designed by hand. That’s where I’ve always seen the delay get introduced. You end up spending lots of cycles on the query so the delay looks like it’s within the DB but when replaced by a custom query the bottleneck goes away. Quite often a quick fix is replacing the query with a store procedure or view and letting the devs work off of that.

The classic example is the N+1 query pattern, where the number of generated queries is linear in the number of rows returned by the first query.

The absolutely worst thing about them is they claim to be database engine agnostic. Surey the most basic stuff maybe, but make your queries a tad bit advanced and it stops working on different database engine. Also, how often do you switch to a database engine that is so much different from your existing one? I hate using Doctrine, stupid query builders make me develop twice as slow. On the other hand, Eloquent is kind of nice and has an easy way to write raw SQL queries.

100%, the extremely 1:1 way that c# translates into sql is prolly the closest to what OP wants, I've tried a variety of ORMs and EF Core us hands down the best I've used.

The fact it doubles as a DB Schema manager and migration engine is just icing on the cake. All my database related needs in one spot.

Parameterization: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html

If you’re at the point where you need the performance boost from raw SQL over an ORM, you have solutions for these problems such as a well-maintained, centralized interface or store for SQL.

OP wasn’t asking for best principles, OP was asking for a language that replaces ORMs. That’s SQL directly in your code.

You can still do that.

For example, you'd still write classes for your tables:

    public class Users
    {
        public int Id { get; set; }
    }

and then you'd just do

   var query = $"select * from {(nameof(Users))} where {(nameof(Users.Id))} = 10;";

That let's you write raw sql about as close as it gets, while still having some degree of type-safety. You could drop a query like that into Dapper, and you're pretty close to just using raw sql.

There are lots of ways to find out what code touches a column. For example, if the code is deployed as stored procedures, you can easily query the text of all stored procedures for references to that column. If it's not deployed that way (maybe in a Git repo somewhere), it's still possible to search that text for the references.

But the problem you describe wouldn't be present if you had good documentation. If developers (front end, back end, and data alike) were able to create documentation that detailed what their code does, and you maintained a knowledge base or data governance platform (like Collibra, though even a wiki would do), you could simple click on the field name and immediately see every article or code reference that uses it as one of their attributes.

Good documentation is all I'm saying. It just usually doesn't exist because the bean counters don't prioritize time to create it, and the developers commonly don't want to (though they'll complain about the lack of it later) or aren't trained to do it effectively.

I am not as familiar with RDBMs internals, but you could also build your server in the database. Right now, I am building a server client of sorts with Oxigraph. I have a store object that I am manipulating directly with rust code. It is an option. However its not going to be very flexible, and it does complicate the sanitization issues.

Also, prolog is a complete language, very capable of running the server. I don't know what kind of architecture you are thinking of and having the distinction between datalog on the database and prolog in the server might be problematic. Also, I may be projecting a little. I wish I could be using prolog. But alas.