February 21, 2018 at 6:46 am
Hello, we have a system that is over 15 years old and our client wants to redesign the system completely. They want to completely change the technology as well. We are going from SQL Server to Oracle (the horror) and ColdFusion to JAVA. In the process, we want to redesign the database and the code but of course the client wants this to happen like yesterday.
Just curious what cut-over and implementation methods other people have used in this situation. Our system has various "modules" (19) that some of them are independent (functionality wise) and some co-mingle with each other. They all share the same database but the DB is quite a hodgepodge of bad coding and bad practices vs. me trying to "fix" stuff for the last 5 years without redesigning it.
They had mentioned redoing one module at a time and releasing that but the thought of me having to write code and processes to make sure the data from the redesigned system is available in the old system and vice versa just makes me cringe. We have a set date for when we need to be implemented by, so I didn't see a good justification for doing this instead of an all or nothing method.
February 21, 2018 at 8:22 am
Start fresh with a new db design!
Do a true logical design -- without NO carryover from current design and NO consideration of physical implementation (Oracle, SQL, etc.). NONE. That's why it's called a logical design.
The db design is the most important thing. Once you get that done correctly, you can go on to designing and creating/modifying code.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
February 22, 2018 at 9:27 am
If I needed to ensure data is available in SQL Server and Oracle at the same time, I'd likely look for a new job. This is going to be a problematic merge replication issue that I'm not sure anyone has solved without constant manual data fixes. If they wanted to have the new system as a read only one where you replicated one way, I'd consider that. But trying to reconcile the data movement is going to be a nightmare.
As Scott mentioned a good db design moving forward should be possible since you know the requirements without looking at the current design.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply