I dig this idea but I'm confused about a few things. The post linked to here from T=Machine mentions that the Flyweight pattern should be used for components (he said this in the context of adding functions to components but since functions are not relevant to Flyweight I assume that he meant the statement to be general). Right below that it says "all data lives in Components; ALL data"...
So I've got a component for "Position". It holds my Entities' 3D position. For it to be flyweight wouldn't make sense since it updates its data to what is basically a random value constantly (creating a bunch of instances!). Maybe he was mentioning Flyweight as only for cases where its useful? I would not expect it to be normally useful but I might have confused the whole thing.
I'm also not sure how I could have, say, a Physics component/system, an Animation component/system and a Collision handling component/system and have them coexist safely. I assume that individual systems need to synchronize with one another but aren't they supposed to be completely distinct? Or is this an "as distinct as possible -- suffer through the synchronization" kind of deal. How can three systems (potentially with order dependencies) update/utilize the same entity's position value?
( Is this similar to categories in Objective-C? Or mix-ins in other languages? Also see Groovy DOM-Categories : http://groovy.codehaus.org/Groovy+Categories )
Finally, the analogy to RDBMS is spot-on. I see the entity idea less as declarative-programming than procedural-programming (which undeservedly got a bad name after its popularity faded). Of course, an OODBMS isn't usually a bad thing either. If they work for your games needs then switching to db4o or something is smart. I find it hard to use because of its object activation policy and I don't have serialization bottlenecks so I haven't bothered but if I did I'd switch DBMS in a heartbeat.