On Wed, 05 Jul 2000, Rob Browning wrote:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > Personally, I think that this is one weakness in the present
> > approach to report generation. I would prefer to see an
> > implementation that does the calculations in the engine (as directed
> > by the report generator) and only does the displaying in the
> > external part. That way we would be able to take advantage of
> > database implementations of the summation in the case that we use an
> > SQL database for the store.
>
> But until we have a better idea of what our data type's going to look
> like, I'm not sure we can accurately evaluate the kind of computations
> we're likely to be able to push into an SQL back end. For example, I
> suspect if we go with something like a rational number library that
> choice will have very different implications for what *can* be done in
> the back end as compared to going with a fixed point library.
> In fact, this might be an important point to consider when specifying
> our new data-type/api if we really believe we're going to stick in an
> SQL backend eventually, and it seems like there's a substantial case
> to be made for that.
Exactly!
Please stop and look at this from the opposite view.
I don't care HOW you store *Whatever* (money). Figure out what properties it
has and what manipulations you need to perform on it. Then find the
"expensive" part of the process and try to design around making that more
efficient. In general, the real specification of the component data types is
the least important aspect and will either "fall out" of the analysis or be
totally inconsequential.
For example, describing the set of "attributes" (eg the memo field, tax
status, type of currency, etc.) associated with a ledger entry
and transferring thousands of them across the interfaces is expensive. As a
result, you will want to push the selection mechanism down toward the data.
When you really look at it, there isn't much that you can do with the "money"
that is left. Most of the activity is "counting" it and "adding" subtotals
together. In general, databases know how to do that.
Whether you use ASCII strings, integers, or floating point to store the
amount is only related to the ability of that format to preserve the
important features of the amount.
Don't tell me that we need to use a rational number representation. Instead
tell me the manipulations that must be performed and cannot be done with
integers. (We have already agreed that one requirement is the exact
representation of the smallest transactional unit. Any amount is an exact
integral multiple of that value.)
However, as I have said before, don't confuse the requirements of "money"
with those of "exchange rates" (prices). They are different. As a result, we
should assume that they will be stored in a different manner. It may turn out
that we use the same representation. However, that conclusion cannot be
reached before the analysis is performed.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
