3 ms·

I was a team once that strongly considered event sourcing. To me, it seemed like a solution looking for a problem. It could have worked for us, but we ended up

I was a team once that strongly considered event sourcing. To me, it seemed like a solution looking for a problem. It could have worked for us, but we ended up passing on it as the benefits were not immediately clear and the risk of doing something new and the lessons learned that would come with it just didn’t seem in the best interest of the project/company. Maybe that makes us tools for passing up a learning opportunity, but I don’t regret getting into that rabbit hole without a fox chasing us down it.

Nextgrid 3y ago
A boring, conventional system that works is a threat to a bloated engineering team who don't have any work to do & polish their resumes with and might feel at threat of redundancy. That is the "problem" this solution solves.
alecco 3y ago
Temporal databases make a lot of sense for financial data, for example. But in most cases you can just have a normal database and store the historic changes in auxiliary tables. So the main database is kind of a materialized view.
- GartzenDeHaes 3y ago
  The traditional way to handle this is to use a GAAP style transaction/journal and a roll-up summary table. The current state can be reconstructed from the read only transaction table and you don't need any complex event processing system.
  - theteapot 3y ago
    > The current state can be reconstructed from the read only transaction table .. Isn't that called event-sourcing?
devjab 3y ago
Almost every piece of data we store in SQL would be better on a document database, but since nobody is familiar with those we keep on trucking. I don’t mind too much, I don’t even think we made the wrong choice, but it does cause us some issues with how we have to handle data model changes. I think most data storage didn’t really keep pace with how a lot of software is being build now though, and things like events and queues are what we build on top of what we have because we need it. For the most part a lot of the data relations happen outside of our databases today through various services, because that’s just how the modern IT landscape looks in many organisations. You’ll have internal master data that supports different teams in the business and interacts with 300+ different IT systems and applications in order to streamline things. With micro services it’s easy to keep the business logic and data models clean, but then you need to manage events, queues and data states as well as reliant storage. Which is just so complicated right now. I do like SQL but these days, the systems we’re building could frankly be put in a SQLite and be perfectly fine, well almost.

Nextgrid 3y ago

A boring, conventional system that works is a threat to a bloated engineering team who don't have any work to do & polish their resumes with and might feel at threat of redundancy. That is the "problem" this solution solves.

alecco 3y ago

Temporal databases make a lot of sense for financial data, for example. But in most cases you can just have a normal database and store the historic changes in auxiliary tables. So the main database is kind of a materialized view.

GartzenDeHaes 3y ago
The traditional way to handle this is to use a GAAP style transaction/journal and a roll-up summary table. The current state can be reconstructed from the read only transaction table and you don't need any complex event processing system.
- theteapot 3y ago
  > The current state can be reconstructed from the read only transaction table .. Isn't that called event-sourcing?

devjab 3y ago

Almost every piece of data we store in SQL would be better on a document database, but since nobody is familiar with those we keep on trucking. I don’t mind too much, I don’t even think we made the wrong choice, but it does cause us some issues with how we have to handle data model changes. I think most data storage didn’t really keep pace with how a lot of software is being build now though, and things like events and queues are what we build on top of what we have because we need it. For the most part a lot of the data relations happen outside of our databases today through various services, because that’s just how the modern IT landscape looks in many organisations. You’ll have internal master data that supports different teams in the business and interacts with 300+ different IT systems and applications in order to streamline things. With micro services it’s easy to keep the business logic and data models clean, but then you need to manage events, queues and data states as well as reliant storage. Which is just so complicated right now. I do like SQL but these days, the systems we’re building could frankly be put in a SQLite and be perfectly fine, well almost.