Merge pull request #136 from prooph/docs

update docs

docs/variants.md

@@ -65,11 +65,16 @@ This stream strategy should be used together with event-sourcing, if you use one
 different aggregates named `user-123`, `user-234`, `todo-345` and `todo-456`, you would have 4 different event streams,
 one for each aggregate.
 
-This stream strategy is the most performant of all, but it will create a lot of database tables, which is something not
+This stream strategy is the most performant of all (with downsides, see notes), but it will create a lot of database tables, which is something not
 everyone likes (especially DB admins).
 
 All needed database tables will be created automatically for you.
 
+Note: For event-store projections the aggregate stream strategy is not that performant anymore, consider using [CategoryStreamProjectionRunner](https://github.com/prooph/standard-projections/blob/master/src/CategoryStreamProjectionRunner.php) from the [standard-projections]((https://github.com/prooph/standard-projections) repository.
+But even than, the projections would be slow, because the projector needs to check all the streams one-by-one for any new events. Because of this speed of finding and projecting any new events depends on the number of streams which means it would rapidly decrease as you add more data to your event store.
+
+You could however drastically improve the projections, if you would add a category stream projection as event-store-plugin. (This doesn't exist, yet)
+
 ### SingleStreamStrategy
 
 This stream strategy should be used together with event-sourcing, if you want to store all events of an aggregate type into a single stream, for example