Thread: tables, where
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
-----------------------------------------------------------------
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
On Thu, 29 Mar 2001, Richard Huxton wrote:
> From: "Mart�n Marqu�s" <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
> 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.
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
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
> 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