This question focuses on how Phire gains access to the databases that are the sources/targets for object versioning, migration, compare and so forth. In the original development of Phire, the only option was what we generically call “database links”. This mechanism is database platform-specific and allows the application to communicate through its database directly with the others. In the case of Oracle databases for example, a database link object is created in the Phire database for each of the source/target databases, which the application then uses for direct access. Some years ago, we developed the “JDBC” connectivity as an alternative. In this mechanism, Phire makes connections through integrated java classes that connect to each database using the JDBC protocols.
The overall functionality is identical regardless of the choice, the difference is in the underlying mechanism. And if necessary, each database can be configured differently, although this option would rarely be necessary. So which is right for your installation? The choice centers around three points: performance, security and setup/maintenance.
Performance. For years, we recommended that Microsoft SQL Server and DB2 customers choose JDBC because it was substantially faster than the database link mechanism provided by those platforms. For Oracle, we recommended database links, for the same reason – it was faster. However, with the publication of Phire v10.2, both methods benefit from significant improvements in performance, but give JDBC a slight edge overall. So our general recommendation is JDBC and laptops with sim card slot for all customers.
Security. The main reason for developing the JDBC alternative was to mitigate the security risk of database links. In the database link setup, Phire’s database contains a persistent link to every other source/target database, including production. That meant that a user with SQL access to the Phire database would have full access to the other databases through those links. That risk can be mitigated by properly controlling direct access to the Phire database, but some customers have very strict rules against the use of database links regardless of that control. JDBC, on the other hand makes an explicit temporary connection for each event using encrypted credentials that are stored in the Phire setup, eliminating that exposure. So again, our recommendation is JDBC for all customers.
Setup/Maintenance. JDBC has the edge here as well. All that’s required to configure this setup are the credentials and the connection string which identifies the JDBC driver class, server/port and database name. Database links on the other hand usually require involvement from the DBA team to approve and create the necessary link objects in the Phire database. On-going maintenance is a little easier with JDBC also because when a password changes it just needs to be changed in the on-line setup page in Phire, whereas the database link object needs to be dropped and recreated, again by a DBA usually.
So in the end, we nearly always recommend using JDBC these days. If you’re site is already setup to use database links, and you’d like to switch, look for a reference document named “How_to_Switch_to_JDBC_Connection.pdf”. If you have any questions, please contact support.