I have a product which has a un-normalized legacy data model which contain millions of records. This has cause problems when adding new features and with performance. Also this contributes to high storage requirements at data file level on databases. I'm looking into a finding some good architectural patterns which i can follow to migrate my data from this current legacy data model to a more normalize modern data model. Are there any good architectural patterns which i can make use of ?
closed as too broad by gnat, Jörg W Mittag, Doc Brown, BobDalgleish, Thomas Owens♦ Mar 17 at 23:45
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
There isn't a particularly good way to transition to a new data model. Ideally you can design the new data model, migrate your data to the new model, and be done.
But many projects can't do that because such a change would be too risky and too big. You then need to find or insert a seam where you can change a part of the system, without these changes affecting the entire system. Such seams are typically some kind of abstraction, for example an interface between two components.
One strategy can be to migrate the canonical representation of the data but continuing to offer the old interface via database views. You can then remove the view after all users have been migrated to use the new datamodel.
Another possibility might be to first refactor the code using the database to only access the database through an interface that you control (→ repository pattern). You can then transition the datamodel while only having to change the code within this repository. Such a strategy can help to migrate one aspect of the datamodel at a time and reduces the risks of this migration. However, this may not be a good fit for CRUD apps.