3 ms·
> You can also design software A to produce both G1 and G2 side by side This can be impractical if G is a database table that is very large. > it’s best imho
by geocar 9y ago
> You can also design software A to produce both G1 and G2 side by side
This can be impractical if G is a database table that is very large.
> it’s best imho to make the projects truly independent, as if they were developed by different companies.
One of our systems might cost £300k, so completely desynchronising them so that code paths can build both G1 and G2 simultaneously (allowing B to develop separately) means "simply" doubling the costs. That might put our team at a disadvantage against someone who figures out another way.
- Groxx 9y ago> This can be impractical if G is a database table that is very large. If this is true, you have no choice, and must run things side by side while you convert to G2. Or shut everything down to make the migration atomic, which is increasingly not an option.
- geocar 9y ago> you have no choice It depends on your database. If you imagine a simple postgres or mysql server and an "alter table G..." then you're right. If (however) G1⊂G2 then a document store or a column-based database can usually partition the table somehow.
- gwenzek 9y ago> This can be impractical if G is a database table that is very large. Unless if the new format G2 is a super set of the old format G1. Read protobuffers best practice to know more about this.