Horton

Thread

  1. tables, where

    Martin Marques <martin@bugs.unl.edu.ar> — 2001-03-29T06:38:41Z

    Hi
Is it a bad idea to put tables of different aplications, even if they have 
somethings in comun, in the same database?

Saludos... :-)

-- 
El mejor sistema operativo es aquel que te da de comer.
Cuida tu dieta.
-----------------------------------------------------------------
Martin Marques                  |        mmarques@unl.edu.ar
Programador, Administrador      |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------

  2. Re: tables, where

    Richard Huxton <dev@archonet.com> — 2001-03-29T16:00:40Z

    From: "Martín Marqués" <martin@bugs.unl.edu.ar>

> Hi
> Is it a bad idea to put tables of different aplications, even if they have
> somethings in comun, in the same database?
>
> Saludos... :-)

Plus points :

+ If you need to join between tables you will *need* to do this

Minus points :

- You will need to make sure tables for application aa and bb don't have the
same name (so aa_contacts and bb_contacts)

- Security: make sure each application runs as a different user and only has
access to the tables is is supposed to.

- It is harder to back up individual applications' data

HTH

- Richard Huxton

  3. Re: tables, where

    Rich Shepard <rshepard@appl-ecosys.com> — 2001-03-29T17:03:51Z

    On Thu, 29 Mar 2001, Richard Huxton wrote:

> From: "Martn Marqus" <martin@bugs.unl.edu.ar>
>
> > Is it a bad idea to put tables of different aplications, even if they have
> > somethings in comun, in the same database?
>
> Plus points :

> Minus points :

  As I have not received an answer to my posted question of a few days ago,
let me try again, under this thread. It's a related question.

  The docs for the 6.x releases described how to use different data
directories under postgres. After trying unsuccessfully with a number of
different approaches, I asked the list and learned that this feature was
broken under 6.x but was scheduled to be working in the 7.x releases. My
question is whether or not (with 7.0.3 or 7.1) I can specify environment
variables such as $PGDATA2 and $PGDATA3, each pointing to a project-specific
data directory, and be able to have postgres recognize (and accept!) that
directory?

  For example, (and this is what I tried with the 6.5.x series), in
~/.bash_profile I have this:

PGLIB=/usr/lib/pgsql
PGDATA=/var/lib/pgsql
PGDATA2=/home/rshepard/accounting/paisley
export PGLIB PGDATA PGDATA2

  I went through the process of registering PGDATA2 with postgres
(supposedly), but I could not use this directory.

  Could I now do this and have it work?

Thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

  4. Re: tables, where

    Mitch Vincent <mitch@venux.net> — 2001-03-29T17:25:06Z

    >   The docs for the 6.x releases described how to use different data
> directories under postgres. After trying unsuccessfully with a number of
> different approaches, I asked the list and learned that this feature was
> broken under 6.x but was scheduled to be working in the 7.x releases. My
> question is whether or not (with 7.0.3 or 7.1) I can specify environment
> variables such as $PGDATA2 and $PGDATA3, each pointing to a
project-specific
> data directory, and be able to have postgres recognize (and accept!) that
> directory?
>
>   For example, (and this is what I tried with the 6.5.x series), in
> ~/.bash_profile I have this:
>
> PGLIB=/usr/lib/pgsql
> PGDATA=/var/lib/pgsql
> PGDATA2=/home/rshepard/accounting/paisley
> export PGLIB PGDATA PGDATA2
>
>   I went through the process of registering PGDATA2 with postgres
> (supposedly), but I could not use this directory.
>
>   Could I now do this and have it work?

    I'm confused as to how this could work.. The PGDATA environment variable
(as I understand it) is used so that you don't need to supply a -D <data
dir> argument to the postmaster at startup. If you had PGDATA and PGDATA2
defined, how does the backend know which to use at startup without
specifying something on the command line -- and if you're putting something
on the command line anyway, why not just say -D <other data dir> ?

    Good luck!

-Mitch
Software development :
You can have it cheap, fast or working. Choose two.

  5. Re: tables, where

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-29T17:49:33Z

    Rich Shepard <rshepard@appl-ecosys.com> writes:
>   For example, (and this is what I tried with the 6.5.x series), in
> ~/.bash_profile I have this:

> PGLIB=/usr/lib/pgsql
> PGDATA=/var/lib/pgsql
> PGDATA2=/home/rshepard/accounting/paisley
> export PGLIB PGDATA PGDATA2

If this is in *your* .bash_profile then it's the wrong thing.  The
environment variables must be set in the *postmaster*'s environment.

The 7.1 documentation for alternative locations is perhaps better than
what we used to have:
http://www.postgresql.org/devel-corner/docs/postgres/managing-databases.html

			regards, tom lane

  6. Re: Re: tables, where

    Rich Shepard <rshepard@appl-ecosys.com> — 2001-03-29T18:10:49Z

    On Thu, 29 Mar 2001, Mitch Vincent wrote:

>     I'm confused as to how this could work.. The PGDATA environment variable
> (as I understand it) is used so that you don't need to supply a -D <data
> dir> argument to the postmaster at startup. If you had PGDATA and PGDATA2
> defined, how does the backend know which to use at startup without
> specifying something on the command line -- and if you're putting something
> on the command line anyway, why not just say -D <other data dir> ?

Mitch,

  I no longer remember the specific syntax, but the -D wasn't working
whether or not another directory was specified as an environment variable.

  In other words, only the default data directory would be seen as valid by
postgres. What I'm asking is if this has now been changed.

Thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

  7. Re: tables, where

    Rich Shepard <rshepard@appl-ecosys.com> — 2001-03-29T18:12:03Z

    > If this is in *your* .bash_profile then it's the wrong thing.  The
> environment variables must be set in the *postmaster*'s environment.

  Aha!

> The 7.1 documentation for alternative locations is perhaps better than
> what we used to have:
> http://www.postgresql.org/devel-corner/docs/postgres/managing-databases.html

  I'm confident that it is. :-) I'll look at them and set things up properly
now.

Many thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com