I totally agree with the doc about making the decision that best fits your needs.
Perhaps it would be a good idea to explain why I recommended not to do this
Many years ago when I was young and naïve (ok just naïve), I made a decision with one of my schools databases to separate all student leavers data into separate tables And there were a lot of tables. We then made another decision to archive all data for previous academic years into separate tables as well...which of course meant archiving all leavers tables for previous years.
The net result of those decisions was four sets of tables instead of one set.
Of course that also meant four sets of queries and in many cases four sets of forms and reports plus all the additional code that went with those.
Every development process from then on took that much longer as a result
We rarely recombined data using union queries as it was unusual for us ever to need more than one category of the data at a time
The screenshot below is from a database statistics thread in the code repository
https://www.access-programmers.co.uk/forums/attachment.php?attachmentid=68466&d=1510279805
The left side of the screenshot shows the huge number of database objects that resulted from those decisions. After a few years, the BE SQL database was approx. 3GB
Of course, it still worked perfectly.
Searches were generally a bit faster because there were fewer records in each table than if they had remained combined.
However, in all subsequent databases we learned from our mistake and made the opposite decision. Instead, we kept the data combined but adding a boolean field to indicate current students or leavers and another field to indicate the academic year for that data.
As a result, development time was much reduced and both FE and BE were also smaller