The Overall Plan
I'm creating a staff "portal" area for a non-profit. In the future I want to migrate the current static front-end website to Drupal, so I thought it would make sense to develop this portal area as a custom module into the back-end Drupal administration.
About the custom module
The non-profit provides a Child Sponsorship program, allowing supporters to pay a monthly fee which pays the school fees for children in East Africa. So the idea of the portal will be that it will reduce the administration of staff by holding the sponsorship database online. The database is split into two: children who are sponsored and children on the waiting list. So I want to produce a module where each child is effectively a node. The node will contain sensitive information such as DOB, Address, School Exam Results etc and so isn't AT ALL for public viewing.
However, that when a child is added to the waiting list, a short bio will feed into the front-end website allowing them to be sponsored. This is one reason for trying to build it into Drupal from the beginning. In the future, it is also planned that when a user goes onto the front-end website, chooses a child to sponsor, they will be made a 'user' in Drupal, and given the ability to view certain information about their child such as a school report.
Questions
Is it conventional use of Drupal to build a module specifically for internal use where primarily the data is not for the public or front-end website? Is it an appropriate use?
To me it makes sense that each child functions as a node of content type 'child', however I'm worried about making them actual nodes.....as I said the data is private, and Drupal currently sets node public at URL node/{nid}
What is the best solution moving forward with creating this database within Drupal? Could I make an equivalent 'node' style format?