1 of 1 people found this helpful
If you store your payments records in a Payments table related to the Students table, there is no need to 'save' or 'export' anything, since you create these records as you need them; performing a Find by studentID and/or date /range) will automatically return a found set of the appropriate records (if they exist), which lets you create a report for January, February or every other date range / criterion.
For example, a database for student management is different every month, so we want to save all the payment records and other stuffs in a 'set' named "January".
No, it's not – what's different are the data in each record, but the structure is the same – and a month can be derived from a date attribute. I take it you don't use one table for male and another one for female students…?
Note that it makes sense to frequently pre-compute figures like a monthly revenue and store those in a dedicated table, which speeds up your database performance, since you no longer need to calculate them each time you need to display them, or use them for other purposes; but the data these figures are based on are still stored in their own table.
Your question as such, and the fact that your screenshots show an enormous number of fields for several of your tables, leads me to believe that you have structural issues. I suggest you read about database normalization, entities and attributes. It's the rare entity that needs 172 attributes for a full description (even accounting for a small number of calc and summary fields), unless you're dealing with scientific topics and 'things', which I gather you do not.