Directly query the database from the application.
- Your application now contains specific code and is tied that application
- If you are in the common situation where the business buys another application containing the same master data, you now need special code to connect to two applications
- Vendor might not like it
- Might be performance impacts on source application
Use Windows Task Scheduler / SQL Agent to run a script or SSIS to replicate data at x minute intervals or so.
- Your application is only tied to your local copy of the database, which you can customise as required. If your source app gets moved to the cloud or something then you don't need to make application changes, just integration changes
- If another source application appears with the same type of master data, you can now replicate that into your local DB rather than making application changes to connect to 2 databases.
- Possibility of stale data
- Even worse: possibility of stale data without users realising it, with subsequent loss of confidence in the application
- Another component to maintain
If you write a batch script, .Net app or SSIS, they are all pieces of logic that needs to be scheduled to run
Another option is to replicate the database using differential replication if your source database is Oracle or SQL, you can use replication to replicate it into another database.
You need to consider where you will be in a few years. The data copy method probably gives you more flexibility to adapt to changes in the source system as you only need to change your integration, not your whole app if something drastic changes with your source system.
You also need to consider: will you ever be asked to propogate changes back the other way, i.e. update data in your local copy and have it pushed back to the source systems.