Re: Using tables in other PostGreSQL database - Mailing list pgsql-general
| From | Swaminathan Saikumar |
|---|---|
| Subject | Re: Using tables in other PostGreSQL database |
| Date | |
| Msg-id | 82692d4a0803272229g24993190o668bbb5694b9f899@mail.gmail.com Whole thread Raw |
| In response to | Re: Using tables in other PostGreSQL database (Jorge Godoy <jgodoy@gmail.com>) |
| Responses |
Re: Using tables in other PostGreSQL database
(Martijn van Oosterhout <kleptog@svana.org>)
Re: Using tables in other PostGreSQL database ("Scott Marlowe" <scott.marlowe@gmail.com>) |
| List | pgsql-general |
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?
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@gmail.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@gmail.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
pgsql-general by date: