I'm pretty sure that that is the model that relational databases (and the SQL language in particular) replaced, back in the 70s or so. Look up "network" databases (eg CODASYL) and "hierarchical" DBs (eg IMS) for some ancient history here. Yeah, you can do it like that, but it's seriously painful to develop and maintain. People were more excited about spending human effort to save machine cycles forty years ago than they are today.
Network database programming is, indeed, imperative; but as I understand it there was not much of a planning layer -- the program was the plan. In C#, one has LINQ; and in Scala and Haskell, monadic comprehensions; and even in Python one can overload iteration to allow a translation of imperative syntax to declarative syntax. The goal with these features, is generally to present a familiar interface to an unfamiliar semantics.
If we imagine network databases have one layer:
Imperative Plan
And SQL databases have two:
Declarative Query -> Imperative Plan
It seems reasonable to say, LINQ, &al. have three:
Imperative Syntax -> Declarative Query -> Imperative Plan
Fortress is rather the same, since it translates imperative to functional to assembly.
