Results 1 to 4 of 4
  1. #1
    Join Date
    Jul 2003

    Unanswered: seismological data

    hi all
    i'm currently applying for a job at a geo physics reasearch center

    what i'd like to know is:
    do you think that PostgreSQL could cope well with extremely large amounts of geo-physical data ?
    (data measured by the geologists and seismologists)

    and furthermore does PostgreSQl work well with other DBMS
    ( possibly the odd legacy kind ?

    thanks in advance

  2. #2
    Join Date
    Sep 2001


    For such special data
    I think postgres is the best solution

    we are now moving to a project with familiar data and I think there will be no real problems with postgres.

    What other legacy DBMS?

    On what level interacting with other DBMS?
    --Postgresql is the only kind of thing--

  3. #3
    Join Date
    May 2002
    Florida, USA
    See for a nice project to add GIS/spatial capability to PostgreSQL. And I agree that PostgreSQL is the best open source DBMS for this sort of work.

    PostgreSQL shouldn't have any more difficulty working with legacy data than any other SQL DBMS. It "talks" to all the standard data interchange formats, such as ODBC, JDBC, etc... (except it doesn't have built-in XML abilities yet) and it allows for easy import of flatfile data.

    Really, usually legacy integration is handled by the application layer to a certain extent. But, since PostgreSQL allows for stored procedures (functions) written in several languages, including Perl, TCL, Python, C, etc... then it is quite possible to connect to external legacy databases from inside PostgreSQL functions.

    For example, running Perl stored procedures in "untrusted" mode allows for procedures to connect to the filesystem to read flat-file data, execute command-line programs and return output, or to load Perl modules to connect to any number of database systems supported in CPAN. Since stored procedures can now return sets, they can be queried to return columnar data in SQL exactly the same way that normal tables do. Thus, it is possible to create procedures which connect to external databases, but which act just like tables inside the database (obviously, this takes some work...).

    Also, there is an add-on module called "dblink" in the /contrib directory of the PostgreSQL source that even allows for connection to external databases from SQL queries and procedures. I don't know how many DBMSs it will connect to, though.

  4. #4
    Join Date
    Apr 2003


    Postgresql is the best , I'm working with it for a while and it's working really fine !
    Open up
    Take a look to my Blog

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts