0

I have an application already written to work with MSSQL and the company has moved on to develop applications using a slower database platform (I will leave it unnamed for now). All the data is to be migrated from SQL to the new slower platform and I am left with the task of changing my app to point to the new platform, at the same time as finding a way to two keep it fast enough so that it will be usable.

Tests have shown that the new platform is slower in the measure of seconds while SQL performs in milliseconds. I have decided that it is going to be impossible to use the new slower database platform to support my app because of what it does. I want the data to stay in SQL.

This leads me to think that I could sync data from the slower platform over to SQL in order to serve my app, however the app also needs to write to the new slower database!

Some more constraints:

  • The app and database are deployed in the same local network.
  • The app allows multiple users to edit data, and prevents users from editing the same record if it is being viewed by someone else.
  • The app relies on at least 15 tables, the largest of which has about 60 columns.

Would syncing the data from the slower database back to SQL and then reprogramming the app to write to both databases at the same time be the most efficient way to to this?

CrazyTim
  • 6,695
  • 6
  • 34
  • 55
  • 4
    Put your foot down and say NO! Or just warn them, in writing (e.g., email) that it's a mistake, then do what they ask and let them experience the slowness. – ErikE Apr 05 '13 at 05:46
  • What is the _reason_ for migration? Perhaps the same reason can be fulfilled with a different DBMS that is less slow? – Branko Dimitrijevic Apr 05 '13 at 11:52
  • @Branko, the company has invested a lot of time/money into the new DBMS. The choice is out of my control. – CrazyTim Apr 06 '13 at 12:24
  • @ErikE, thanks, you inspired me. Perhaps there is still a way to retain ownership of my data and keep it in SQL... – CrazyTim Apr 06 '13 at 12:25

0 Answers0