On Wed, Jul 05, 2000 at 09:10:12PM -0500, Christopher Browne wrote:
>
> 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.
I do not understand why this would be the case. It is probably true that most
SQL DBMSes do not offer rational numbers as a data type, but you can simulate
one by having two integer columns per rational number to be represented; row
selection is atomic in DBMSes, so there shouldn't be any problems with
consistency. This will make operations like sorting and taking averages a
royal pain in the neck, but IMHO that will be true for any implementation of
rational numbers. C will absorb the complexity better than SQL will, because
SQL sucks as a programming language, but that is one of the tradeoffs you make
when you move to an SQL-based RDMS.
If sorting and doing statistical analysis of the rational number data turns
out to be a major performance bottleneck (which I doubt since, in the current
incarnation of GnuCash, I don't see much of either being done), a possible
solution may be to add a third column that contains a floating point
approximation of the rational number, which is updated every time you update
the rational number. This bloats the database by almost a factor of two and
adds more complexity to the SQL backend, but for a big, business-sized
database, it may possibly be worth the tradeoff.
> 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.
--
Shimpei Yamashita <http://www2.gol.com/users/shimpei/>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
