Have Geek Brain

Is the communication between the two applications SSIS?

Working with a team of more traditional developers, we faced this situation:

We have a growing number (two now) of applications that will access some common data inserted through the ui of one of the applications, which could be called the main administrative application. Since other applications just need some data or it has to be formatted using a different schema, one suggested solution is to have a database for each application and a sync job at a specific frequency that updates data from one db to another, I was too fast to ditch this solution in favor of a service-oriented solution, where data is stored in a single master repository and accessed through open services.

So, I would like to read your thoughts, as I think that I might be biased in favor of relative new technologies and might not appreciate the value in more traditional solutions.

+2


a source to share


1 answer


My advice when choosing a technology is to really weigh the pro versus con. "New" versus "Old" can fall into traps all the time. There will always be a hot new buzzword for something or the other out there at any given time, and it may or may not be a good way to go. So analyze:

Pro SSIS package and service:

  • You can transform your data into target databases to match your referential integrity relationships.
  • Easily access and modify existing applications to access this data.
  • If you have a small amount of data to convert, this task will be fast.
  • The SSIS package is a nice, centralized place to debug data transformation tasks.
  • Security can be made easier by transforming data using SSIS. You don't need to worry about potential issues like Kerberos delegation between service and service.
  • Accessing the data itself at destinations will be much faster because you don't have to make another service request. You can simply join the data already in your database.

Con for SSIS package and service:



  • You don't have real-time access to the raw data at your destinations.
  • If there is a large amount of data, or if the package is poorly written, it can take a long time.
  • If you have a rapidly growing number of target databases, you will need to change your SSIS package frequently.
  • You can customize your security mechanism with the service so that you can control and verify access to your information.
  • If your target systems need to write back to a central source, combining this whole piece together with SSIS can be a real pain.

So, I weld this:

If you go back to a centralized source or you can't have a significant delay between updates, the service makes a lot of sense. Otherwise, it is recommended to copy the data using SSIS. In my place, we use SSIS to transform our user data and import it into our systems databases, but we use services to implement a system-wide registration infrastructure.

+4


a source






More articles:


All Articles