5 ms·
The current relational database is too limiting. We're dropping all sorts of interesting data on the ground because we don't have suitable pigeonholes to put it
by chadly 12y ago
The current relational database is too limiting. We're dropping all sorts of interesting data on the ground because we don't have suitable pigeonholes to put it into.
That is the best description of the problem event sourcing tries to solve that I have seen. Short and to the point.
- mrits 12y agoI disagree. I mean sure, I put humans and radiation in the same pingeonhole, but thats more of a devops problem to work out.
- solipsism 12y agoMaybe to someone who's already familiar with other, longer descriptions of the problem. I don't know what problem this is solving and that description doesn't do much for me. Can someone either explain, or point to a fuller explanation, of the purported problem?
- Terr_ 12y agoThere are some overlapping architectural ideas here, I find they build upwards like this: CQRS: You have one "write" data-model which is specialized for transactions and applying business rules... and other "read" models that take care of things like dashboards, detailed information pages, searching, generating reports, etc. Chronological events: A really handy way to propagate changes from the write-model into the various read-models. Event-sourcing: This is "dogfooding" your own events. Instead of just emitting optional messages to other systems, you make them essential, and use them as the authoritative record for your own system's state. This adds certain kinds of flexibility that you may (or may not) need.
- dj-wonk 12y agoIf one describes CQRS as being mostly about a write (e.g. master data) + read (e.g. derived data) combination, how far could one get with a relational system with views and triggers?
- Terr_ 12y agoPretty far, I imagine, especially with things like materialized views... I'm just biased against putting more logic into the DB than strictly necessary, given the difficulty of versioning that logic and how the DB is often the bottleneck among multiple webservers.
- jamii 12y agoThis is an excellent explanation - http://blog.confluent.io/2015/01/29/making-sense-of-stream-processing/ http://blog.confluent.io/2015/01/29/making-sense-of-stream-p...
- CmdrDats 12y agoThanks jamii, that's an excellent read - I forgot to add it to the Further Reading section! Will do that now :)
- reubano 12y agoVery nice!Here's a good follow up on the inner workings of onyx. https://github.com/MichaelDrogalis/onyx/blob/0.5.x/doc/user-guide/internal-design.md https://github.com/MichaelDrogalis/onyx/blob/0.5.x/doc/user-...
- Terr_ 12y agoI'd add: "All data-models have strengths and weaknesses. The event-log is weak on its own, but its strength is that it nurtures an ecosystem of other models for specific use-cases."
- deleted 12y ago[deleted]
- dragonwriter 12y ago> That is the best description of the problem event sourcing tries to solve that I have seen. Huh. I always thought that the problem event sourcing was trying to solve was more that modeling complex interactive systems through their static state rather than modeling the interactions directly as the principal domain objects is invariably futile. While "we're dropping all sorts of interesting data on the ground" may be one manifestation of that, I think the more common manifestation is "we bear too high of an expense when adapting our information system to changes in business process".
- solipsism 12y agomodeling complex interactive systems through their static state rather than modeling the interactions directly as the principal domain objects is invariably futile Now that actually makes sense to someone not already familiar with the context.