Is it conceptually correct to compare Projections in EventStore with SQL in a relational database?
As a way to query the data storage?
Thanks.
Jan
think this is a good way of looking at it… greg mentions in this post that “Projections are the query language of the Event Store”.
However
they are definitely more powerful than just querying; i.e when utilising emit and linkTo functions enable you to generate new events based on some logic.
If you haven’t already - have a look at Greg’s series on projection at the http://geteventstore.com/blog/ - starting here.
Thanks Joseph,
Yes I’ve read the EventStore documentation and Gregs blog.
I’m just looking for a simple but fairly correct way to describe Projections to others.
Regards,
Jan
I found that simplest way to describe projections is the following (and it worked in our company):
Projections are persisted view models, consider them as a persisted cache. When we do a query we essentially transform data from the “source of truth” storage form (normalized DB, or streams of events) into some other form.
“Select” operator in SQL does it: it transforms data in another form. This process is called “projecting” and the result of a Select statement is in fact a projection. But it is not persisted anywhere so we have to do it again and again every time we execute that Select statement. Especially when we read more than write.
Sometimes (very often) our Select statements are somehow complicated: joins, criteria, etc., even some calculations. If we know that we execute the same kind of query over and over again, meaning that we project our data over and over again into the same king of form, then why not do it just once, keep it somewhere (cache) and then just read it from “cache” every time we need it? By doing this we will have much less load on our DB server as well. This “cache” is only updated when we change something, otherwise it just stays the same no matter how many reads we do.
So this is your “projection” conceptually: a piece of persisted data that is updated periodically. This data is usually in 1st normal form and ready-to-use in some specific scenario. Just what SQL query would return if we needed the same data, but faster (because it is pre-done and cached), nothing fancy here.
Now, projections can be stored anywhere. They can be stored in files, or in mongodb, or even in SQL server if we really need to (we can have a row per a view model, or just a blob field, etc), wherever it is convenient, it does not really matter much because persisted projections are cache, they are not the source of truth (it is worth mentioning from time to time for DBAs).
I explained it in this way to the team and to managers and it worked 
Hope it helps,
Alexey.