We have a database which has a number of tables that all utilise different identification methods for currencies. Some use ISO numbers other tables use ISO Codes. All the data and (and effectively) structure of these tables is from outside third party sources, so there is no influence on how and the format of the data produced.

We have a table that is a Currency table that contains both ISO number and ISO alpha codes, and a CurrencyId (just a simple integer: 1, 2, 3 etc).

We have an ETL that imports the data, and in some tables, the data is converted at import time from one currency identifier (eg ISO number) to the other currency identifier (eg ISO code). This I think is a result of different, incongruent, teams working on the software but that is a topic in its own right lol.

We have a .net software application that references these tables directly, and obviously there's no consistency in which ISO code (number or alpha) that the software is referencing.

It is also proving difficult to maintain code by referencing sometimes the ISO code and other times the ISO Number for the currency.

So we are considering one of the following resolutions:

  1. Import all data and map at that point a new derived field (we are using SSIS) that is the CurrencyId for that currency from the "Currency" table based on the ISO code number or alpha (and still import the currency identifier that the original data does). Then change the references in the software to utilise the CurrencyId instead of the currency ISO code or number.


  1. build views for all the relevant tables and join them to the currency table on either ISO number or ISO code (whichever relevant). Then change all the references in the software to reference the view instead and utilise the CurrencyId instead of the currency ISO code or number.

We would like some advice and input as to which would be better approach for a performance perspective. Data storage perspective I imagine will be a small impact since I think the CurrencyId can be contained within a tinyint datatype field, but still very interested to know what you think in this area too.

1 Answer 1


The common sense approach would be to cleanse and sanitise the data on import. Creating a view to mask the problem is not fixing the underlying issue, it's just hiding it.

Also, having the views is unlikely to be a one stop fix, you'll likely need to write other code in other places to work around the issue, which will all need to be maintained.

Having code that works around a problem might be the quicker of the options, but in the long run it will create more work and problems than fixing the data as it comes in to the system.

  • Thanks, we implemented the change to the data import side. As you said, it wasn't really practical to create views for everything. It didn't actually take as long to implement either. Feb 3, 2017 at 11:22
  • @KeerKolloft no problem, you've just saved yourself a lot of future head aches. Do you work with the OP?
    – Tanner
    Feb 3, 2017 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.