Interesting coverage of our project on the SQL-Ledger-users list

["Chris Travers" <..hidden..>]

The thread is at:
http://sourceforge.net/mailarchive/forum.php?thread_name=1314.76.95.44.123.1212947229.squirrel%40www.clustersolutions.net&forum_name=sql-ledger-users

I wanted to go ahead and open the discussion over here on a few relevant points.

The first one has to do with my complaints about SQL-Ledger's database
structure.  In general, my concerns have been:

1)  Lack of appropriate NOT NULL constraints (for example on
acc_trans.chart_id) mean that it is possible to insert bad data from
the application without it throwing an error.
2)  Use of IEEE floating point types for money means that there can be
roundoff errors.  I have seen this at least one time where a larger
user of SQL-Ledger had a $0.02 imballance in the books due to roundoff
errors relating to the datatype.
3)  Honestly, this is a lesser concern:  The lack of normalization and
foreign key constraints makes integration more brittle and risky.
However, it is a lesser issue even here than #1 above.

Note that the first issue can affect anyone, the second issue can
affect anyone putting enough transactions into the db, and the third
one probably only impacts system integrators and those doing custom
code.

The second issue has to do with the structure of the community and
questions of conflict of interest.

LedgerSMB uses a republic model for our project  We have a core
committee in which no company controls more than one of the six
current seats.  The core committee's main duties are to protect the
interests of the project, to manage core infrastructure, and to make
decisions about architectural matters.  Five of the six members have
commit rights.  The structure is designed to prevent the project from
going down a path which is good for one company but bad for the
project or community.  Multi-vendor support is one of our core values.

The major questions relating to the decision to move specifically to
PostgreSQL, and which versions of that database manager we should
support have largely been made on the following considerations:

1)  Maintainability of code
2)  Complexity of QA
3)  Accessibility to vendors
4)  Ease of integration with other solutions.
5)  Our statement of vision.

In short, we want to build a quality accounting program which can be
used by a wide number of businesses, where they can get support from a
number of sources, and where they can integrate the software with
other applications.  Because integration solutions at the db level are
available (DBI-Link), maintainability of code and complexity of QA
become larger concerns.

I would like to invite people who have any concerns about the
community or our direction of development to come forward and voice
those here on the list.

Best Wishes,
Chris Travers