OO is great for systems, where you have real objects, and only care about their current state. In effect - for simulations, games, such stuff.

In most systems - changes over time, archival data, and relations between objects are important. And with OO it's ugly to keep them. You end up implementing relational db backed by object collections. And your nice objects instead of representing nouns (Employee, etc.), start representing relations (Employement, etc.).

So people use relational db with ORMs and load everything from database into objects only to show window/edit data, call one or 2 methods on these objects, and save data back into database. All this ceremony to write employee.giveRaise(raise) instead of giveRaise(employee, raise).

And yet this problem kind of goes away in a key value or graph database. I wonder if the ORM mismatch is often not one of objects getting in the way, but one of using relational in the first place. At anyrate, how you manage your objects (for things like search) is ideally orthogonal to the objects themselves; though this is difficult to accomplish in practice.

I use objects in reactive (non-persistent/DB) systems all the time. Objects aren't the problem, but you do have to manage your dependencies dynamically by tracing/dirtying/and cleaning. Objects actually excel at encapsulating and managing state, it is much harder to do this with functions (see all the work on functional-reactive programming).

Hm, I've never used key-value/graph datastore, and it seems I need to. Is there something like selects with joins for graph nodes? How do you represent changes in objects over time?