3 ms·
I mean, sometime along the way you’re going to have something that consumes the data (otherwise, why bother keeping it in the first place), and that something w
by Althorion 2y ago
I mean, sometime along the way you’re going to have something that consumes the data (otherwise, why bother keeping it in the first place), and that something will have certain expectations about the way things are structured.
It will probably become a good idea then to have some clue as to what structure used to be at one point or the other, and for that you’d want to keep track as to what got added/removed and when.
If it’s a very early stage in the development, and you don’t expect any of the current data to survive to the final version, I guess that’s fine. But when you have an actual running product that has to keep running, dealing with the multiple versions of the data scheme is a pain, and dealing with the multiple untracked versions of the data scheme is a pain squared.
- TekMol 2y agoHow does "have some clue as to what structure used to be at one point or the other" relate to the topic of columns vs json fields?
- Althorion 2y agoIt is what they meant by ‘tracking’, which is what you’ve asked about.
- TekMol 2y agoI have the feeling you both are confusing your development workflow around database structure with the structure itself. You seem to think that using columns somehow results in some type of automatic "tracking" (versioning?) of something.
- Althorion 2y agoNot quite. We are saying that adding `not_available_before: 2026`, or similar, ‘right away’ is usually not a good thing; therefore anything that helps with doing that is not something we desire. It should be a multistep process. Yes, it will waste time now, but it will save it in a long run.
- TekMol 2y agoHow will it save time in the long run?
- jitl 2y agoI use a lot of JSON columns w/ SQLite and find a programming language type is a great way to specify schema for such a column without having to write any migrations. No one has written a sternly worded comment at me on the internet yet for adding or removing fields from my struct types without writing a separate migration file. Lots of use-cases for SQLite are not like Big Iron SQL Database Of Record where every change must be tracked because it's a shared stateful single point of failure and there's hell to pay for mistakes or confusion.