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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
