Trust me on this. It may seem OK right now, but I can absolutely guarantee that you will wish it was a table sooner or later. Only use dropdown or radio elements for choices that (pretty much) never change - "Favorite Color" or "Gender", and that you don't need to do any kind of "stuff" in your own code with. OK, so gender is getting a little fluid these days, but you know what I mean.
For anything that you may want to "do stuff" with (including getting an array of values and labels), or that may change, create a table, and use a join set to dropdown or radio.
So to get that array of all of the values and their labels from my example table ...
Code:
$db = JFactory::getDbo();
$query = $db->getQuery(true);
// replace with your currency table name
$query->select('*')->from('currency');
$db->setQuery($query);
$currency = $db->loadObjectList();
// you now have an array of objects with the values and labels
If you wanted to index your array by the "label" ...
Code:
$currency = $db->loadObjectList('label');
... so you can then access the $currency array keyed by the label, like $currency['MYR']->value.
This is probably one of the most frequent issues I wind up having to help people correct in their projects over time, where they used a dropdown element, and find that as they add functionality, they need that data to be in a table.
The other pitfall to avoid, when using tables instead of dropdowns, is using anything other than the primary key ('id') as the "value" of the join. The temptation in your case would be to use the 'label' ('MYR') as the value you store for the join, because it seems intuitive to store the actual currency name in your currency element. But that's not how relational databases work. Always use the 'id', so it's an actual FK (foreign key).
-- hugh