The notion that nothing has changed about B-Trees or sorting algorithms doesn't, I think, actually hold up... but this question is more like changing the API for a standard-ish B-Tree library than about modifying how the B-Tree itself works.
As an aside: LINQ is the only “ORM” that is truly worth using. It is integrated into the language and you can use the same expressions and query expressions are first class types that can be passed around as expression trees and are then only translated either as code if you’re using in memory lists, database specific SQL, MongoQuery etc based on the provider you pass the query to.
I've been thinking a lot about ORMs and they almost usually fall flat at some level since they are not nearly as expressive as a first order language is. I haven't had experience with LINQ but I know the Django ORM is this way.
I'm thinking the best approach if I had time/money would be to develop a better query language that is close enough to SQL for people to learn, but then also translates back down to SQL. LINQ looks really close to this, but I'd really want it to be cross language.
One of the aspects of QUEL that I really liked was that if you couldn't describe what you wanted, you could program it out if you needed to. Say you had some complex ranking algorithm that was hard to write in SQL directly.
Have a look at EdgeQL, the query language that powers edgedb.
Cross language will still be an issue. LINQ isn’t really an “ORM” it is a method to translate C# commands used to work over related collections to expression trees and those expression trees are interpreted/translated at runtime by a provider.
You need support from the language/runtime to treat expression trees as a first class type.
expression tree parser. It’s not for the faint of heart.
Not if it uses CTEs or other advanced SQL features. It can do basic select, join, group, sure. But that's just scratching the surface of how powerful SQL is. As for requiring language support: in Elixir, Ecto.Query essentially implements a LINQ-like DSL as a library (albeit with macros). See https://hexdocs.pm/ecto/Ecto.Query.html
In C#, if you did something like this
var seniorMales = from user in users where u.Age > 65 && u.Sex == “male” select u
seniorMales is just an IQueryable<User>
Later on you could say
var gaMales = seniorMales.Where(s => s.State == “GA”)
var floridaMale = seniorMales.Where(s => s.State ==“Florida”)
All three of those are just expressions that have not hit the database yet.
Then when you want to actually run the query and limit the number of rows, you can do
var result = floridaMales.Limit(20).ToList()
It would then create a query including a limit clause just as you would expect it to.
Now if you do
floridaMales.ToList().Limit(10)
It would return all of the rows in the table to the client and it would be limited on the client side (don’t do that).
Worse case, if LINQ can’t express in query syntax, a provider can add its own extensions in function syntax and the provider can still parse the expression tree.
LINQ also can't do window functions. Like I said, it covers the basics of SQL that most applications need. But as soon as you need to go beyond that you'll be writing custom SQL.
I grew up with SQL so LINQ for a long time just reads so weird to me. I won't admit how long it was before I realized this fact you stated.
It still reads weird to me, but I get it.