Re: external table
От | Albe Laurenz |
---|---|
Тема | Re: external table |
Дата | |
Msg-id | A737B7A37273E048B164557ADEF4A58B17D16F06@ntex2010i.host.magwien.gv.at обсуждение исходный текст |
Ответ на | Re: external table ("John R. Sowden" <jsowden@americansentry.net>) |
Список | pgsql-novice |
John R. Sowden wrote: > I write programs using the foxpro/dos language (I run them using > ubuntu/dosemu). It seems that the languages that I must write my > database applications in, using pg apis, are c based. In reading books > on the issue, the quote that stands out in the first few pages is "if > you understand c, then you won't have any problem learning ..." I bout > the kernigan 7 ritchie book in the 80s and decided that that is > ridiculous, unless I wanted to get a job writing software. There are PostgreSQL APIs for a lot of languages, including Perl, Java, Python, .NET and many others. They are not part of the PostgreSQL distribution, they are other open source projects or commercial offerings. Here is a good list: http://www.postgresql.org/download/products/2-drivers-and-interfaces/ I doubt that anybody writes PostgreSQL applications in C. > My programs are not just a list of queries and input forms. One is an > accounting program (GL) another is an AR/billing program, etc. > > re: the external lookup table, I assume that I will more all of my dbf > data to pg, not maintain a foreign table (foreign to pg). I am wondering > how to create queries, etc. relating a table that is not inside the > connected database. I expect to have separate databases for gl, > billing, dispatch, service call tracking. Now each of these are > separate tables (.dbf files). These are not flat files, they are > relational. One PostgreSQL database can contain many tables. You can organize these in Schemas. I would advise that you keep all tables that are used by one application in one database. It is no problem if several applications access the same database. Since PostgreSQL 9.3 there is a foreign data wrapper (postgres_fdw) that allows to access tables in different databases, but you should have a really good reason for that, because it means a performance penalty, complicates the architecture and does not guarantee that modifications to both databases are atomic (i.e., it may happen that the transaction succeeds in one database and fails in the other). Yours, Laurenz Albe
В списке pgsql-novice по дате отправления: