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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
