If the modules are all vastly different, and require multiple tables for the data, then I would suggest multiple databases, and bring the fields you need from the teacher table, such as id and name, in as variables for your queries on the different databases.
If the modules have very similar table structures, (one may use a field that another does not, but most fields are identical in structure), then I would suggest, instead of seperate tables for each module, create a "module" table with the module name and id, and create a field in your tables to refference which module the table belongs to, or create a table for nothing but crossing the data to the module id's. I have parts databases in which one part may cross to several machines. Here's basically how I set up my tables to handle the joins:
Parts Table
id
part_num
descript
.....
Machines Table
id
machine
descript
.....
Cross_Ref Table
part_id
machine_id
I have found that joining that tables that way gives me maximum flexibility in what I want to do with the data, as well as making updating easier.
I also have quote and order databases which refference the parts databases and part_id's for their joins. They are vastly different from my parts database, and even each other, so I keep them quite seperate. On the web interface that I use to access them, it seems as if they are all one entity, happy and unto itself.
