A lot of people seem  to believe that RelationalOperationsAreOnlyForDatabases that they can not be used for other non persistent operations...
I dont think that is a GoodIdea, I think that if we have AritmeticOperators and BooleanOperators as PrimitiveOperators in our ProceduralLanguages or ObjectOriented languages, we should also have RelationalOperators to manipulate local collections, that would open the door for very powerful optimizations like parallel search for data, parallel aggregate function execution, parallel translation from one data structure to another (from Dictionary to Array for example), etc. It would also make some algorithms a lot easier to maintain and ready, making software development more conceptual (like in ConceptProgramming)

See also: RelationalBreaksEncapsulation
------------------

Yes, that is what everybody says, RelationalBreaksEncapsulation... why we say that only against Relational? Procedural also breaks encapsulation, Functional also breaks encapsulation... in fact, if we were to have "perfect" encapsulation, then objects wouldn't collaborate with each other, if we can live with the fact that procedural needs to somehow manipulate objects, why we can not live with the fact that Relational also has to "touch" objects to do its work?

* Note that "breaking encapsulation" is not necessarily bad. The point is that the "rules" of OO are not valid or not accepted in the relational world, and perhaps visa versa. The two are thus somewhat at odds with each other. (EncapsulationBreaksRelational.)

** The "rules" of OO can be perfectly valid and accepted in the relational world, as long as it is recognised that the RelationalModel is categorically '''not''' an alternative to OO (or vice-versa), but is simply an expressive and composable means for defining and manipulating collections of values.  The RelationalModel and OO approaches complement each other.  OO and Relational are only "at odds" when one tries to force a 'tuple/row' = 'class instance' equivalence.  That equivalence is demonstrably wrong, and has been persuasively debunked by HughDarwen and ChrisDate in TheThirdManifesto.  If one uses a 'tuple attribute value / row^column intersection' = 'class instance' equivalence, then an implementation of the RelationalModel within an OO language simply (and powerfully) adds Relation and Tuple to the usual Stack, Vector, Hash, Map, etc. collection classes.  Conversely, an implementation of the OO model within a RelationalLanguage simply (and powerfully) provides a useful means for defining tuple attribute types.  It is not the case that RelationalBreaksEncapsulation -- any more than using any other collection mechanism or type definition system breaks encapsulation. -- DaveVoorhis

''Functional and procedural don't actually break encapsulation.  Functional accepts only those parameters to a function that you offer it, and so never needs to peek under someone else's skirt.  Procedural performs as requested of it, which may involve sending messages to or accepting messages from other components... but it needn't knowledge of or access to how those other components are implemented.''

----
ObjectVsModel, RelationalBreaksEncapsulation, JulyZeroSeven (for this an the related pages)