|
|
|
|
|
by runeks
1147 days ago
|
|
I'm torn on this subject. It's not a simplification in my view, but just one way to achieve a goal that has pros and cons. The big pro is that you no longer need to remember to update tableB, which is derived from data in tableA due to performance, in your application code every time you update tableA. The cons are that: * You add more state to your DB * You can't express the logic in your backend language Thinking more about it, I don't think the cons outweigh the pros. I would prefer this trigger logic to be part of the DBMS, so I can express the logic in my backend language and also avoid increasing the dependency of my application logic on DB state. |
|