I am thinking about re-architecting a set of Enterprise databases I use.
Currently, there are three databases that are
shared databases and that interact with each other.
These databases each have Forms and Procedures in them to interface with their specific data.
Whenever any of these Forms or Procedures are updated or modified in any way, there are several steps in the workflow to update these databases both on the server and ensure all the clients/users get the updates.
Additionally, once these changes have been made, all users must update their databases in order to continue accessing the data and all users then get the new UI components, regardless of whether they want or even need those changes.
THE PROPOSED SOLUTION
So, I was thinking of re-architecting the whole system by, essentially, separating out the “UI components” from the actual data.
In essence, I’d move all the “UI components” (Forms/Procedures) out of each of the shared databases into one (or more?) non-shared databases.
These non-shared databases would load the shared databases as “secret” databases and pull data, as needed, from those databases.
I am hoping this kind of separation would allow for easier, and selective, updates of the UI without requiring all users to update at the same time.
The only “global” updates that would be required would occur if/when the actual data structure (fields add/removed) of the data is modified.
- Has anyone done this kind of approach?
- If so, what your experiences and “pros” and “cons” that you’ve discovered with this kind of approach?