Timeline for Favoring Immutability in Database Design
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 27, 2020 at 8:31 | comment | added | k3b | Related: In Domain driven design there are immutable Value Objects and mutable Entities. For details see softwareengineering.stackexchange.com/questions/22352/… and stackoverflow.com/questions/4581579/… | |
| Dec 7, 2018 at 9:04 | comment | added | Michael Borgwardt | @cirrus: for some systems you might be right, for others you are spectacularly wrong. Storage may be cheap, but you still need to process the data. Indexes. Backups. You could easily end up causing more problems as you solve. | |
| Dec 7, 2018 at 9:00 | history | tweeted | twitter.com/StackSoftEng/status/1070966294114168832 | ||
| Jun 3, 2013 at 2:58 | comment | added | Izkata |
@Fosco Some systems are absolutely required to never delete data (including using UPDATE). Like doctor's medical records.
|
|
| Jun 3, 2013 at 2:15 | answer | added | James Anderson | timeline score: -1 | |
| Jun 2, 2013 at 19:55 | answer | added | kisai | timeline score: 18 | |
| Jan 17, 2013 at 21:32 | comment | added | cirrus | I think there's a strong argument for immutability within databases. It solves a lot of problems. I think the negative comments have not come from open-minded people. In-place updates are the cause of so many problems. I would argue that we have it all backward. In-place updates are the legacy solution to a problem that no longer exists. Storage is cheap. Why do it? How many DB systems have audit logs, versioning systems, need for distributed replication which as we all know requires the ability to support latency for scale. Immutability solves all this. | |
| Oct 12, 2011 at 4:32 | answer | added | James Anderson | timeline score: 7 | |
| Oct 11, 2011 at 20:45 | answer | added | psr | timeline score: 1 | |
| Sep 5, 2011 at 20:31 | answer | added | Mathias | timeline score: 8 | |
| Sep 5, 2011 at 20:24 | vote | accept | Ed Carrel | ||
| Sep 5, 2011 at 17:55 | answer | added | Matthieu M. | timeline score: 0 | |
| Sep 5, 2011 at 8:01 | answer | added | Ryan Culpepper | timeline score: 27 | |
| Sep 5, 2011 at 6:05 | comment | added | snakehiss | There can be good reasons to avoid updates in databases. However, when these reasons do come up it's more of an optimization problem and as such shouldn't be done without proof that there is a problem. | |
| Sep 5, 2011 at 6:03 | comment | added | Ed Carrel | I think it was more a matter of having an intuitive idea of a solution in mind, and wanting to run it by as many people as possible, and in the process realizing that this may not be the best solution to the problem I have. I may open a different question with the problem, provided I can't find it elsewhere. | |
| Sep 5, 2011 at 2:52 | answer | added | Rei Miyasaka | timeline score: 27 | |
| Sep 5, 2011 at 1:53 | comment | added | Fosco | I feel like this is a solution without a problem... You should be updating, rather than creating elaborate adaptations to avoid updating. | |
| Sep 5, 2011 at 0:23 | history | asked | Ed Carrel | CC BY-SA 3.0 |