Обсуждение: pgaccess - where to store the own data
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? Iavor -- www.pgaccess.org
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
>> 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
>> 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 ------------------------------------------------------- -- terry
Compiling the latest CVS fails when using --with-tcl Found while testing 7.3 for pgaccess-0.98.8 beta 1. Attached is a patch. It's just a Makefile touchup now that pgaccess will no longer be included with postgres. --Chris Maj -- cmaj_at_freedomcorpse_dot_info 0xC0051F6A 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A
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}
I fixed that yesterday. Thanks. --------------------------------------------------------------------------- C. Maj wrote: > Compiling the latest CVS fails when using --with-tcl > Found while testing 7.3 for pgaccess-0.98.8 beta 1. > Attached is a patch. It's just a Makefile touchup now that pgaccess > will no longer be included with postgres. > > --Chris Maj > > > -- > > cmaj_at_freedomcorpse_dot_info > 0xC0051F6A > 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A > Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > 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. These days you could create a schema in the database you're managing as well... Chris