On Friday 08 February 2008 02:53:45 Oleg Broytmann wrote: > I have, as I have a few Decimal columns in the database of one of our > company's commercial programs - we count money (dollars and cents). Until > now none of our customers has problems, though I doubt one has tried to > sum up all those cents and fractions.
If I can find the time, I'd like to implement a double-entry journal/ledger accounting system in SQLObject. Accounting reconciliation involves strict equalities; even slightly inaccurate recording of cents & fractions causes a lot of unnecessary extra work. That's why I'm afraid of floating point. I am too dumb to understand sqlite's data storage model, but quick consultation of Google yields up this conversation from just last weekend: http://www.mail-archive.com/[EMAIL PROTECTED]/msg31198.html """ The case I'm dealing with that is not working like I want is the case of NUMERIC column type. In SQLite, this column type gets an affinity of REAL. If I put in a value to the column as a string literal, say '123.23', it's stored as a REAL even though I specified it as a string in quotes. [...] I want to avoid the use of REAL types in this case because they can lead to rounding errors, which is the whole purpose of the NUMERIC type to begin with, in my understanding. """ Needless to say, this frightens me. But rather than dropping the ideal of serverless installs of desktop apps, I am interested if there's a better way. > If you find a problem - please publish more details. In case of PySQLite > there is a way to map data to/from strings for any data; currently > SQLObject uses this feature to map strings to/from unicode, and map > date/time strings; it would be possible to add a mapping for Decimals. That sounds like a better way! Strings should be a fine way to store fixed-point numbers of finite length. Are there any considerations that might make this a bad idea? cs ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
