I do not believe such a thing would be possible in a DBD driver.

You need a look at the SQL statements that the system uses. If you have 'SELECT id FROM user' this makes things simple. However if you have "SELECT * FROM $X" it would require you examine the surrounding code. A lot of systems abstract the DB calls into a module. If this just wraps a simple SQL execute that is not much of a problem but if the SQL is generated on the fly it could a long time to work out what is happening.

The easiest way to reconstruct the schema would be to write a script that first extracted the current SQL and its location in each script. You might be able to create a fake DBD driver that dumps the SQL to a log and then returns an empty results set. Again SELECT * is your enemy. It should never be used but people still do it and never think of what happens if someone addes a blob contain Gbs of data to the table.

Thinking about this you might be best with a DBD driver that returned an empty set for know SELECTS but died on SELECT * allowing you to investigate further. INSERTS, DELETES AND UPDATES should just be logged.

Such a DBD driver would be interesting but would probably be more work than parsing the original code for SELECT, UPDATE, INSERT and DELETE.

Hope it helps
UnderMine