[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why no LedgerSMB name space
- Subject: Re: Why no LedgerSMB name space
- From: Berend Tober <..hidden..>
- Date: Sat, 01 Dec 2012 18:32:17 -0500
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
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