in reply to How to display all the content of the database?

Well, something is going to need to know about the structure of your database (even it it's just a list of tables to dump). This knowledge can be encoded in one of two places. The most common is that your program needs to understand the relationships between the various tables.

The more flexible and generic (but far less common) solution would be if the database designers encoded this information in the database itself by using referential integrity constraints on all of the tables in the database. In this case you would be able to query the metadata tables in order to construct SQL to query the real tables. One possible problem is that the metadata tables vary a lot between different database systems - so a solution like this wouldn't work on different systems. I believe that the DBI team are working on adding generic metadata support to the DBI spec, but I don't know how far they've got or how well supported it is in individual DBD modules.

Executive summary - you probably can't do it.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

  • Comment on Re: How to display all the content of the database?

Replies are listed 'Best First'.
Re: Re: How to display all the content of the database?
by Alex the Serb (Monk) on Jan 09, 2003 at 12:29 UTC
    Hi,

    sector(s_id, d_id, name);
    department(d_id, dd_id, name);
    division(dd_id, ... , name);
    ...
    ...
    ...
    goes for unknown depth.

    I thought that it have something to do with data dictionary, but can it be done using DBI. DBI is independent of database, does DBI have some part that addresses common things of every data dictionary, like geting informations about relations between tables, informations about primary and foreign keys ...

    Am I more specific now?

    Some people did this, but they charge money for this!

    Anyway, I tried this but using Perl's Pg modul for PostgreSQL. There is table pg_databases, pg_tables and stuff like that from which you can determine some of stuff, but can it be done using DBI and MySQL. And it have to be general.

    UPDATE:
    If the company add some new relation that is in relationship with another one, it should be displayed without changing the script.
[reply]
      Howdy!

      We are making some progress here.

      However, I have some concerns.

      You say:

      sector(s_id, d_id, name);
department(d_id, dd_id, name);
division(dd_id, ... , name);

      [download]

      That looks a bit backwards from a normalization point of view. It appears that the higher level entity contains a pointer to the lower level entity, which is exactly backward from how it ought to be.

      Consider:

      sector(s_id, name, ...)
department(d_id, s_id, name, ...)
division(dd_id, d_id, name, ...)

      [download]

      In this rough schema, a department has a sector ID. In your schema, either a sector has to have multiple columns for department IDs or there have to be duplicate sector entries if a sector has more than one department.

      Now, to get back to your actual question, if your requirement is simply to be able to use DBI, then without prior knowledge of the set of tables, you cannot depend on being able to discover the relationships, since not all DBDs offer that kind of support (DBD::CSV, DBD::RAM, for instance).

      If you must use DBI with any arbitrary DBD for the data store, you will have to know up front the set of tables to examine. You won't even be able to count on getting a list of tables in the "database".

      yours,
      Michael

[reply]
[d/l]
[select]
        Sorry, I switched in a hurry :)

        ... however, you got it. It could even be a database that contains products and their parts and services that goes for unknown depth level. But, no matter how deep it goes and what is to be displayed, the script have to display parent entity and all of the tuples of its child entity and then all tuples of child entity (which is parent in this turn) and all of tuples of its child enitities, etc.

        It has already been done, using PHP and MySQL, but I'm doing things in Perl.
[reply]
      does DBI have some part that addresses common things of every data dictionary, like geting informations about relations between tables, informations about primary and foreign keys ...

      I think I already answered that. Please reread my previous answer substituting your phrase "data dictionary" for my phrase "metadata" - they mean the same thing :)

      --
      <http://www.dave.org.uk>

      "The first rule of Perl club is you do not talk about Perl club."
      -- Chip Salzenberg

[reply]

In Section Seekers of Perl Wisdom