4
The module has several data in the database. Of course the tables created by the module, but also an entry in the module table, where all modules are listed. This entry contains the module number the mid. This id is used in various other tables as reference to the module. They have a field that is named mid or contains mid in the name (sometimes modid or mod_id). Examples are the tables for blocks, comments, configuration (where the preferences are kept), group permissions, templates and notifications.
So, a lot of information is woven in the database. Depending on the module it is easier to recreate the exact status of what is was before. The biggest problem is that the module id is a consecutive number for every install. When you restore to another system, the number may already be taken. Overwriting will be a sure inroad to disaster.
When you get a new module id, all refencing data must be altered.
For most modules an install with restore of the tables created by the module (see sql file) would work together by a review of all permission and admin settings.
For more complex modules, it may be necessary that other data has to be present for eg the created categories. In normal use, for eg creating new categories, the category record is inserted together with eg a permissions record. When changing the category permissions, both records are updated.
If you have the category inserted by the restore operation and you modify the permissions of the category, the update for the permissions record will fail, because it was never inserted and does not exists.
That also category numbers get their number at creation, may further complex the situation for getting all the reference numbers right.