Re: [gnue-supply_chain] Re: Clients and financial years

[Chuck Rouzer]

> At 9:35 AM +0100 3/24/01, Reinhard M?ller wrote:
> >1. Multiple clients (I mean several different companies running a single
> >installation of gnue)
> >I see 3 possibilities:
> >a) A database per client: simplest solution, but several drawbacks:
> >Tables cannot be shared between clients, data can not (easily) be copied
> >between clients, current databases systems tend to loose performance
> >with many active databases and so limit the number of clients.

        But is it trivial to connect the sources via native database
connections?  Also you can throw a lot of hardware at databases these
days.  Just curious, are multiple instances the same as multiple databases
in this respect?  Which is often common.

> >b) A set of tables per client, with the client number being a part of
> >the table name (e.g. supply_chain__base__item01): AFAIK some systems go
> >this way, but I don't know if I like it personally. Not sure about
> >advantages and disadvantages. Not sure about how many tables may be in a
> >database.

        Seems like this could get ugly, but I don't know.

> >c) A single set of tables where data of all clients sit, with every
> >table containing a field with the client id.

        I like this way better, but I like multiple databases/instances 
even more.

> I think that company should be part of the database structures.  For 
> companies that operate internationally it is typical to have to do 
> accounting on many companies and at the same time run the supply 
> chain as if all of the companies were one company.

        I agree in regards to GNUe doing all EDI in the background and
appearing as "one company" supply chain view.  Very advantageous.  

> For this to work, security must be considered.  I see two scenarios here:
> a) companies have to be completely separate.  this would apply to ASP 
> or others running multiple companies on the same system and the 
> companies are really separate.
> b) multiple companies who have separate accounting but really operate as one.

   I prefer seperating the data into multiple databases or
instances.  Each company would have their own instance/database and
there is flexability in where to authenticate GNUe, via database or via
the local systems configured manor (via pam, NIS, or local, etc).  EDI
software modules could be "plugged" into GNUe to map and connect data.

        This may or may not be the most efficient way of doing
things.  But even low end servers are becoming closer to "old school Big
Iron" status and running multiple databases or instances is not a
problem.  And quite frankly, I wondered how they could squeeze even more
performance out of PostgreSQL when I read that speed is *still* being
increased.  Amazing.