Re: Using tables in other PostGreSQL database

I am fairly new to Postgres. However, I have to say that I agree with
Barry's comments.
The community's response is technically valid; they do talk about a better
way of 'designing' things, and what the company 'should' be doing.
However, coming from a MS-Sql world, people want multiple databases for
different reasons. Sometimes, they are in different departments, and they
keep their own databases, as in Barry's example. Sometimes, a billing
database is behind a firewall for security.
There are multiple ways to do the consolidation, by copying over data to a
common database with multiple schemas. However, the core question of Barry's
has not been answered.

1. There is a feature for cross-linking databases
2. That feature is available as an add-on
3. That feature is very useful for a lot of users, who are not as
knowledgeable as the PgSql community, and who are used to doing that for
other databases
4. Why not provide that feature as a core feature, rather than an add-on? If
the community really feels strongly about this, discourage this practice
with a best-practices section, citing problems with examples, and
workarounds. But why don't you provide this feature out of the box? After
all, isn't widespread adoption of a high quality database like Postgres our
overall goal?

On Thu, Mar 27, 2008 at 6:08 PM, Jorge Godoy <jgodoy(at)gmail(dot)com> wrote:

> Em Thursday 27 March 2008 08:29:04 Pettis, Barry escreveu:
> > An addon???? Being self schooled in databases to me this seems to be a
> > kludge. If you work in a large company environment the odds that
> > someone somewhere is all ready storing or collecting data that you need
> > ( by this I mean base data ) could probably be pretty high. So why, if
> > PostGre is so old/established, is the ability to share information
> > between databases have to be done through an add on.
> >
> > So let me give an example to help clarify.
> > 1. I work in a manufacturing environment
> > 2. Our product can have 150 to 450 different / unique process steps
> > 3. We have a description of each process step
> > 4. So with a product we can look at it's flow and see the descriptions
> > of each step
> >
> > Now say person A pulls this information on a daily basis and then
> > summarizes the product manufacturing information and creates a table
> > that has say the total number of process modules ( aka group of steps ),
> > the total number of steps, the total number of a particular type of
> > step.
> >
> > Now let's say that another person NEEDS that very information in a query
> > or table in their own database. Are you saying that each person needs
> > to generate this. To me the sharing of information seems to be so basic
> > that within a said postgre server, that as along as you have access to a
> > said database you should be able to say use the data stored here. And
> > that that ability should be a rudimentary ability not an addon.
> >
> > Reason why I don't' have ability to install addon's onto the database.
>
> It sounds to me like your company could make a good use of a DBA to
> organize
> all that.
>
> Users should just use the data, not plan the database and keep multiple
> copies
> of information around.
>
> One person designing all this would be able to organize the information,
> keep
> its integrity, safety / secrecy and while doing all that also provide the
> people using the information a better way to get it.
>
> If everyone is creating their own database, then getting access to the
> information isn't the biggest problem. Guaranteeing that all reports are
> generated from the same information -- imagine sales reporting something
> from
> last month while marketing is doing the same for this month and
> manufacture
> is insterested on the history for the same month but comparing it to the
> last
> three years history? A big mess...
>
>
> --
> Jorge Godoy <jgodoy(at)gmail(dot)com>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>