Re: pgaccess - where to store the own data
От | terry |
---|---|
Тема | Re: pgaccess - where to store the own data |
Дата | |
Msg-id | 20020830184956.82E214769A4@postgresql.org обсуждение исходный текст |
Ответ на | pgaccess - where to store the own data ("Iavor Raytchev" <iavor.raytchev@verysmall.org>) |
Ответы |
Compiling 7.3 --with-tcl fails
Re: pgaccess - where to store the own data |
Список | pgsql-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 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
В списке pgsql-interfaces по дате отправления: