Re: Database schema for universal usage
From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 01 Jun 2005 11:43:23 -0400
Message-Id: <rp11n2-nsu.ln1_at_pluto.downsfam.net>
>
>
> Yes, SAP is a good example, and extremely expensive, of
> an application *and* database that can be configured for a
> range of differing requirements. Many many control switches
> behind the scenes, parameters being thrown in the general
> arena to establish the specific end result.
>
> One approach to the general question asked in this thread
> is to split the schema into modules, and then ask the same
> question.
>
> Invariably one has a core organisation/business module of
> some description (dependent upon what the organisation
> does). But associated with the main business module, are
> a series of (presumeably) integrated financial modules:
>
> CORE=main business module
> AR=accounts receiveable
> AP=creditors
> PY= payroll
> FX = fixed assets register
> GL=general ledger
>
> Variance between the financial modules will exist dependent
> upon differing legislative requirements in each country, but
> in general the financial modules will be very similar, whereas
> the differences between the core business modules of various
> organisations will (of course) be extreme.
>
> Undoubtedly there have been various attempts to generate
> universal financial modules, and while everything looks good
> on paper (as someone else observed) in practice, a number
> of heavy duty issues emerge.
>
> The primary issues are related to the fact that these modules
> in the end must be integrated, and the interfaces between
> the modules are not necessarily trivial - hence generalisation
> problems emerge.
>
> The CORE module must feed the AR module usually by
> raising invoices. There may be an interface from the AP
> module to the CORE for expenses to be itemised prior to
> invoicing and recharging. AP, PY and FX must also integrate
> into the GL. The major interface is usually the AR to GL one.
>
> So, this is one manner of making components of your
> problem, and hopefully may assist in understanding the
> problem from another perspective.
>
>
> One other approach to this general question is to ask the
> question whether anyone has made a study of "collections"
> or "classifications" of schemas, seeing that some schemas
> are similar, while others are diversely disparate. I dont
> know whether anyone has done a study like this.
>
> But if such a study were made, you would at least have
> (in theory;-) a review of the field which is to be somehow
> made universal.
>
> 2c
>
>
Date: Wed, 01 Jun 2005 11:43:23 -0400
Message-Id: <rp11n2-nsu.ln1_at_pluto.downsfam.net>
mountain man wrote:
> "Paul" <paul_at_test.com> wrote in message
> news:427f906e$0$578$ed2619ec_at_ptn-nntp-reader03.plus.net...
>> Chris wrote:
>
>>> On the level of business management some ideas >>> exist for a company-wide database. However on a technical base I did >>> not find any information about this idea - or any descriptions of >>> people how has tried it. Still looking forward... >> >> Although I've never used it, there are companies like SAP that I >> understand provide massive off-the-shelf database installations that are >> supposed to cover large amounts of standard business requirements. But >> that's only because things like accounting, payroll, etc. are fairly >> standard across companies.
>
> Yes, SAP is a good example, and extremely expensive, of
> an application *and* database that can be configured for a
> range of differing requirements. Many many control switches
> behind the scenes, parameters being thrown in the general
> arena to establish the specific end result.
>
> One approach to the general question asked in this thread
> is to split the schema into modules, and then ask the same
> question.
>
> Invariably one has a core organisation/business module of
> some description (dependent upon what the organisation
> does). But associated with the main business module, are
> a series of (presumeably) integrated financial modules:
>
> CORE=main business module
> AR=accounts receiveable
> AP=creditors
> PY= payroll
> FX = fixed assets register
> GL=general ledger
>
> Variance between the financial modules will exist dependent
> upon differing legislative requirements in each country, but
> in general the financial modules will be very similar, whereas
> the differences between the core business modules of various
> organisations will (of course) be extreme.
>
> Undoubtedly there have been various attempts to generate
> universal financial modules, and while everything looks good
> on paper (as someone else observed) in practice, a number
> of heavy duty issues emerge.
>
> The primary issues are related to the fact that these modules
> in the end must be integrated, and the interfaces between
> the modules are not necessarily trivial - hence generalisation
> problems emerge.
>
> The CORE module must feed the AR module usually by
> raising invoices. There may be an interface from the AP
> module to the CORE for expenses to be itemised prior to
> invoicing and recharging. AP, PY and FX must also integrate
> into the GL. The major interface is usually the AR to GL one.
>
> So, this is one manner of making components of your
> problem, and hopefully may assist in understanding the
> problem from another perspective.
>
>
> One other approach to this general question is to ask the
> question whether anyone has made a study of "collections"
> or "classifications" of schemas, seeing that some schemas
> are similar, while others are diversely disparate. I dont
> know whether anyone has done a study like this.
>
> But if such a study were made, you would at least have
> (in theory;-) a review of the field which is to be somehow
> made universal.
>
> 2c
>
>
This is why you've got to put the spec into data. We know how to manipulate data, but manipulating code is much harder.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Wed Jun 01 2005 - 17:43:23 CEST