Skip site navigation (1) Skip section navigation (2)

Re: pgaccess - where to store the own data

From: terry <tg5027(at)citlink(dot)net>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: pgaccess - where to store the own data
Date: 2002-08-30 19:12:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
>>  Iavor Raytchev wrote:
>>  > Hello everybody,
>>  >
>>  > There is an open question we need broad opinion on.
>>  >
>>  > Currently pgaccess stores its own data in the database it works
>>  > with. Some people do not like that. To store it elsewhere invokes
>>  > a number of issues such as:
>>  >
>>  > - where is this somewhere
>>  > - converting form all versions to the new
>>  > - etc.
>>  >
>>  > What do people think about this. Is it so bad that the own data
>>  > is stored in the database pgaccess works with?
>>  I don't particularly like it. Oracle deals with this by having a
>>  database unto itself as a management repository (Oracle Enterprise
>>  Manager, OEM, I believe). You register the database you want to
>> manage with the repository, and the metadata is kept there instead
>> of in each managed database.

>>  Joe

I would agree that pgaccess's metadata should not necessarily be stored 
in with <all> of the rest of the data being used by a pgaccess 
application.  However, having a central repository as described above 
may make it difficult to distribute an application without providing 
some capabilities to distribute/manage a portion of the central 
repository - which could be ugly for the developer and an end user.

From my experiences using m$access to augment existing applications, I 
would think that at least two sets of data would need to be handled by 
pgaccess - some in an existing database, and some in the pgaccess 
application.  Hence, the structure of m$access with it's 'linked' and 
local tables in the application database itself.  For self-contained 
applications, no linked tables would be used, and the existing format 
is fine for distributing an application.  But, a major strength of 
m$access is it's ability to use data from multiple sources (databases), 
while the application database uses them transparently.  

In any case, where there are multiple users (say > 3 people) the data 
is usually separated from the application metadata anyway for 
maintenance purposes.  That way it is not necessary to do live changes 
or to pass large data laden databases about for an application 

Hence, I would vote to retain the existing method, and put the effort 
into the ability to open multiple 'other' databases on a table by table 



In response to

pgsql-hackers by date

Next:From: Joe ConwayDate: 2002-08-30 19:16:14
Subject: Re: source code indexer
Previous:From: Laurette CisnerosDate: 2002-08-30 18:57:17
Subject: source code indexer

pgsql-interfaces by date

Next:From: C. MajDate: 2002-08-30 19:16:24
Subject: Compiling 7.3 --with-tcl fails
Previous:From: Matthew T. OConnorDate: 2002-08-30 18:43:38
Subject: Re: [HACKERS] pgaccess - where to store the own data

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group