Timeline for Favoring Immutability in Database Design
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 5, 2011 at 20:24 | vote | accept | Ed Carrel | ||
| Sep 5, 2011 at 9:10 | comment | added | Dave Sherohman | There's a little more to it than atmoicity. The argument I see most often in favor of immutablity in an OOP context is that immutable objects only require you to validate their state once, in the constructor. If they're mutable, then every method which can change their state is required to also verify that the resulting state is still valid, which can add significant complexity to the class. This argument potentially applies to databases as well, but is much weaker, as db validation rules tend to be declarative rather than procedural, so they don't need to be duplicated for every query. | |
| Sep 5, 2011 at 6:00 | comment | added | Ed Carrel | Thanks for the answer. This perspective was just what I needed to realize that my intuition was confusingly trying to combine a couple of different ideas into a single pattern. | |
| Sep 5, 2011 at 3:20 | history | edited | Rei Miyasaka | CC BY-SA 3.0 |
added 1 characters in body
|
| Sep 5, 2011 at 3:04 | history | edited | Rei Miyasaka | CC BY-SA 3.0 |
added 42 characters in body
|
| Sep 5, 2011 at 2:58 | history | edited | Rei Miyasaka | CC BY-SA 3.0 |
added 124 characters in body
|
| Sep 5, 2011 at 2:52 | history | answered | Rei Miyasaka | CC BY-SA 3.0 |