By ensuring that there are no un-connected output ports keeps the code readable and helps the code do exactly what it is supposed to do, nothing more and nothing less. It keeps any future developers from wondering or getting distracted on what the un-connected output port was supposed to do and make any changes based on assumptions. It also ensures providing a clean code that encourages other developers to keep it that way.

Possible reasons and motives for leaving un-connected output ports:

• Developer is in a hurry – Developer does not want to bother about all the lineage a particular data point goes through and just disconnects the port connection to the target to disable that port being used in the target
• Port un-linked by mistake
• Negligence

Exceptions (if it ain’t broke don’t fix it)

Sometimes in a mapping with complicated logic, the developer notices that a part of the mapping that he/she is not expecting to change/impact has ports that are un-connected. In this case it may be prudent to leave the port un-connected and note it as something that needs to be re-visited as a separate change. So that the original change is intact any issues can be analyzed to the actual change and not any MOT type of changes.

Use Undraleu^® to perform an Automated Code Review of your Informatica PowerCenter Code and get a best practices perspective on the health of your ETL code

To find out more visit Undraleu^® or the Undraleu Block on Informatica Marketplace at
Informatica Marketplace

There are situations where the quality of the source data (or lack of it) makes it imperative to make allowance for a degree of designed data leak that can be managed externally as a step prior to loading the data into staging tables or target tables. However, a tleast we should start with a design in mind that assumes the data is clean for further downstream systems.

Use Undraleu® to perform an Automated Code Review of your Informatica PowerCenter Code and get a best practices perspective on the health of your ETL code

Find out more about Undraleu visit Undraleu® or the Informatica Marketplace at
https://community.informatica.com/solutions/1624

Most ETL tools come with transformations to perform lookup. In a “perfect” dimensional model, the ETL process will perform lookups on dimensional tables to lookup dimensional data. This is the traditional use of a lookup. A further and advanced definition and use of lookups is in detecting what the “update strategy” of an incoming data should be. While these are very common uses of lookup transformations, they aren’t always ideal.

Most lookup transformations support database table/view/synonym lookup, or flat file lookups – don’t quite know if any do on XML files yet. For tables/files with small foot print, lookups are very performance friendly. Most lookup implementations provide facilities to cache data persistently or in a static way. On the face of this, caching sounds very useful to improve performance of the ETL process and is easily bought as a means to improve performance. But as is the case with most features used in-appropriately, here is where lies a potential mine-field of performance bottlenecks.

Purely because of how easy they are to use and also because of some developers preferring it against an extra join in SQL, lookups are used not just to perform on smallish sets of data but on tables that would generally not qualify as lookups. This often happens when the developer is running against tight deadlines or because he or she does not have enough appreciation of the overall application and its performance requirements.

While there is no sure shot number of records for a table to be lookup-able, a general rule of thumb is to use lookups on fairly static data (non-transactional) e.g. location of a store and resist against any transactional type of table.

More on this soon..

Use Undraleu^® to perform an Automated Code Review of your Informatica PowerCenter Code and get a best practices perspective on the health of your ETL code

To find out more visit Undraleu^® or the Undraleu Block on Informatica Marketplace at
Informatica Marketplace

A major occupational hazard inflicting a Software Programmer is the constant craving to develop software that is complicated even if to solve a simple problem. The satisfaction derived out of a complicated solution can only be subsumed by another even more complicated solution and a vicious cycle is guaranteed to ensue.

The result is a complete ignorance of supportability, maintainability and readability of the software program. One aspect of software programs is their very short life but this somehow seems a forgotten point even by the most skilled of developers. Generally, it is those who are most skilled that build programs with a pride that ignores the rule of short life assuming what they have built to be everlasting.

Often, it is those of the lesser skilled developers who tend to develop the program in simpler components which by definition are easy to maintain, support and readable. Perhaps they may not scale or may look downright disgusting to the better skilled, but ask any support manager which brand of developers they prefer and the answer may be a bit un-comfortable to those hot shot coder crowd.

Not to conclude but to just begin the discussion, keeping the code simple is more difficult than writing complicated programs.

Use Undraleu^® to perform an Automated Code Review of your Informatica PowerCenter Code and get a best practices perspective on the health of your ETL code

To find out more visit Undraleu^® or the Undraleu Block on Informatica Marketplace at
Informatica Marketplace