mal unabhängig von der Frage, ob es real überhaupt "0,xx COP" gibt, stellt sich die Frage warum eine solche Software nicht intern und in der
DB mit einer "passenden" normalisierten Einheit programmiert wird?
Wir arbeiten im Finanzbereich intern seit der Euro Einfühung quasi mit dem "USD Fixing zu diesem Zeitpunkt" für alles und jedes als unsere interne "UniversalExchangeUnit" abgekürzt "UEU".
Bei Zeiten speichern und rechnen wir nur in UTC... Wenn in Japan oder Kolumbien sich jemand was aktuell BTC mit 0,0000xxxxxx eingibt oder anzeigt, ist das nicht viel anders wie wenn er es für was wertvolle wie Gold XXXX,xxx tun würde.
(Wenn Kunden mit den Augen rollen, weil sie mit den internen Daten in unserer
DB nix anfangen können, bekommen sie als Dienstleistung passende "ReadOnly" Views und können sich je nach Gusto dann an ihren "NullNullXvalues" oder "BigValues" erfeuen)
Klar ist das eine Konzeptfrage, aber bei sauberer Trennung von
GUI<->
DB<->BussinesLogic sollte das doch kein Problem sein. Dann reichen in der
DB auch Numeric/BCD und in Delphi "Currency/FixComma".
Und Astronomen sowie Pysiker machen es doch auch so clever... die verrechnen normalisierte Werte und Einheiten getrennt und normalisieren zum Schluss nochmal das Ergebnis auf eine passende Basiseinheit mit sinnvoller Genauigkeit.
Das machten die schon mit Rechnenschiebern so und machen es auch heute mit Computern noch so... die versuchen garnicht erst eine Zahl im Wertebereich bis 10^ +18 auch noch mit einer Genauigkeit auf 10^ -18 zu definieren... die haben&nutzen entweder das eine oder das andere, und bleiben so immer in ihrer konstanten Genauigkeit (hier im Beispiel 18Stellen), egal ob tausend Stellen vor dem Komma, oder tausend Stellen hinter dem Komma.