Quick note: I have 19 days to figure my client's problems out.
Background: Client hired a contractor who boasted he could get a new App out the door in 3 months. Two months and some days later I'm brought in and the individual was let go; there is no complete code, no thought put into the schema, and an abomination for a UI.
I have two applications: one production and mature and the other that needs some love. One has all the data I need and the other that doesn't. I'm writing new code TDD style and aiming for a partially jury rigged SOA infrastructure that covers all issues but the data itself. If I had more time I could use liquibase to refactor the schemas into abomination shards ( use your imagination ) but I don't...so plan B is as follows:
App A (inserts|updates|deletes) entity Foo which updates AppASchema.FooTable which via a post trigger updates the AppBSchema.FooLikeTable and vice versa.
I know this is an insane idea but its the least of the worst ideas I've got, my concerns are
- Possible to create an endless loop (AppA trigger updates AppB which updates AppA )
- There isn't high load, but this basically doubles ops to n*2 so if I hit half the capacity of the MySQL server, it seems like would be effectively at or near full capacity for basic stuff like updating indexes and such.
- As a mixed blessing, the original schema designers made all tables InnoDB engine... thats horrible for performance but could this setup ensure a higher chance of keeping integrity.
My time budget to implement the triggers is 12 hours or bust.