On 05 Jul 2000 15:36:27 EST, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> 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.
I don't think it's as simple as looking at one or the other; there
will be implications that cross the lines.
I would anticipate that having the basic representation be via
rational numbers (e.g. - numerator + denominator in each entry) will
_prevent_ using an SQL DBMS, because SQL DBMSes generally do not
contemplate that representation.
While SQL implementation may not be _imminent_, a bit of thinking ahead
to avoid road blocks against the use of SQL in the future would be a
Good Idea.
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
"...Deep Hack Mode--that mysterious and frightening state of
consciousness where Mortal Users fear to tread." -- Matt Welsh
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
