3 ms·
You can't take into account the fact that things change when you don't know what those changes might be. You might end up needing to either rebuild a new databa
by vrighter 10mo ago
You can't take into account the fact that things change when you don't know what those changes might be. You might end up needing to either rebuild a new database, have some painful migration, or support two codepaths to work with both types of keys.
- groundzeros2015 10mo agoYou can’t design something by trying to anticipate all future changes. things will change and break. In my personal design sense, I have found keeping away generality actually helps my code last longer (based on more concrete ideas) and easier to change when those days come.
- dpark 10mo agoIn my experience, virtually every time I bake concrete data into identifiers I end up regretting it. This isn’t a case of trying to predict all possible future changes. It’s a case of trying to not repeat the exact same mistake again.
- groundzeros2015 10mo agoI don’t disagree with that, I’m disagreeing with this comment that we can’t make protocol or data decisions that might change.
- dpark 10mo agoI misunderstood then. I interpreted your comment to say that you eschew generalization (e.g. uuids) in favor of concrete data (e.g. names, email addresses) for ids in your designs.
- mkleczek 10mo agoNetwork protocol designers know better and by default embed protocol version number in message format spec. I guess you can assign 3-4 bits for identifier version number as well. And yes - for long living data dealing with compatibility issues is inevitable so you have to take that into account from the very beginning.
- vrighter 10mo agowhen I designed network protocols this is exactly what I did. I also did so in file formats had to create. But a database primary kea is not somewhere where that can be easily done.