Question

I am trying to figure out the best database/data architecture approach for a system where I need changes to raw “lower level” tables to, ideally, automatically propagate up various different tables that store views based on the underlying data.

Let me give an simplified example.

Imagine I have the following tables:

1. various table of food ingredients and prices at different supermarkets
   • eg. a Safeway table that has { ketchup: 1.19, butter: 0.99}, and a Walmart table with { eggs: 1.99, butter: 0.79}
2. a table that stores the cheapest location for each ingredient
   • eg. { butter => walmart: 0.79}
3. a table that stores recipes with the cheapest price of the recipe (made up from the cheapest prices of ingredients from table 2.
   • eg. { “ketchupy-egg-breakfast => total: 3.97, ingredients => butter: 0.79, eggs: 1.99, ketchup: 1.19
4. a table that stores the cheapest a breakfast recipe among several alternative recipes.

Now imagine I have workers going out and updating the values of table (1) on an hourly basis. Is there a database design or architecture that would force an updating of any entries in table two that rely on something that changed in table 1, and similarly would propagate changes onwards to table 3 and table 4. I imagine that can be implemented in code through a series of cascading jobs but I was wondering if there was a less complex and more elegant way of doing that.

Thanks for your help.

Answer 1

Looks like a well fit for the CQRS pattern. You should have just one data source when storing items.

From the linked article:

CQRS stands for Command Query Responsibility Segregation. It’s a pattern that I first heard described by Greg Young. At its heart is a simple notion that you can use a different model to update information than the model you use to read information.

CQRS helps you take in one kind of information (Update model) and then transform it into something which you can query (Read/query model).