You will need to have the connection string "somewhere" so your module can access it.  I would avoid putting it in the web config just by virtue of DNN updates (and you may forget to copy that over into the new file).  You *could* create a config file within your own module that has it, or store the connection string as a setting (and require that it be configured when the module is first placed).  Otherwise, you should be able to just go forward creating the module using the core concepts, such as inheriting controls from PortalModuleBase or UserModuleBase (all depending), packaging them up and deploying them.  You will not be able to use the DNN data provider because it is centric to the DNN core, but you can easily create your own data objects (SqlConnection and SqlCommand) to grab your data.

As far as wanting a moduleid or not, that depends on your implementation.  Does it need to be tied to a specific module instance, or will it be that no matter where you drop the module it always has access to the exact same data?  If you need it to be instance specific, then add a ModuleId column of type int, if not, then don't bother adding one.

Also see: Connecting to another database