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.

- Handyman