Re: pgaccess - where to store the own data
От | John L. Turner |
---|---|
Тема | Re: pgaccess - where to store the own data |
Дата | |
Msg-id | 200208301657.22191.jlt@wvinter.net обсуждение исходный текст |
Ответ на | Re: pgaccess - where to store the own data (terry <tg5027@citlink.net>) |
Список | pgsql-interfaces |
On Friday 30 August 2002 19:18, terry wrote: > >> 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 > modification. > > 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 > basis. > > Regards, > > terry =============== Well, I thought I was the only one that want to do that. Please give this "linking" serious consideration. Maybe even the postgresQL folks can help in this area. I have used it in MS Access for 9 years, and it does work well. Where there is a will, there is a way ! -- John Turner JCI Inc. http://home.ntelos.net/~JLT "Just because you do not know the answer does not mean that someone else does" Stephen J. Gould, {rip}
В списке pgsql-interfaces по дате отправления: