Michael Richardson wrote: > > Berend> So for instance some application that did a really good job in > Berend> project management or some other complimentary-to-lsmb > Berend> application domain could be integrated (a little more) easily > Berend> with the financial system (than if separate data bases where > used). > > maybe. care to give an example? >
I cannot detail a concrete example of an actually existing such set up, but I have this grand (... maybe it's just grandoise ...) vision where there was some (or many) complimentary application(s), say for example project planning as suggested, and there was a need to bill for work on the project elements as defined in the project plan. There would likely be a need (and a preference) to join (rather than to duplicate) project management tables with employee time and attendance records for invoicing purposes or maybe for reporting actual project progress and billing (from lsmb) against planned progress estimates and work remaining (from the project management data base). Or say you have a really good application focused on managing detailed customer information, maybe with detailed history of customer activity that from lsmb's perspective you might not really care about except in aggregate for billing purposes. The CRM app could happily provide its special functionality while lsmb got only what it needed for billing purposes. Or there could be a really powerful human resources management application that handles employee benefits in some custom way specific the the organization or industry that will never be implemented in a general purpose accounting application. In these cases, separate data bases would require some sort of export-transform-load solution. Or I suppose it could be accomplished with a software library and supporting application that connects to multiple data bases simultaneously, and maybe that would be about the same amount of work to develop and maintain for an integrated system. But one or both data bases would have to maintain some sort of state regarding the other data base, like what has been exported/imported and how imported rows relate the data back in the other data base. A consolidated data base could enforce relational integrity between the cooperating application data bases. And there is all the machinery of stored procedures and triggers that could play a role in the coordination so separate apps don't accomplish the same end via different ordering of steps and maybe introduce inconsistencies. It is not hard to imagine that there might be table naming conflicts if all applications required defining everything in the PUBLIC name space. In addition to the join tables such an approach would require, there might very well be other data worth sharing between multiple apps, such as location names and postal codes. Those might be good candidates to live in the PUBLIC name space and could survive independently of upgrades to lsmb and other applications using separate name spaces. And you get consistent snapshots of all the related data for backup and replication. ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
