This editorial is very apropos for me. I'm involved in a new project to take an old, legacy application written years ago as a Microsoft Access app, into modern technology. Of course, since someone unknown in the past threw the Access app together, there is no documentation. To compound the difficulties, for reasons unknown, 2 business analysts are working on redoing the database. And they don't give us the whole thing, or even allow me (the developer) or the DBA to review the schema that they're developing. Instead, they'll dole out a new table definition, about once a week, and tell us to pull data from one or more of the old database tables, to put into the new table. It really frustrates the DBA, as he's recently finished an expensive course (for which he paid for) on database design. So, now he's just relegated to writing the SQL script to get the data out of a table/some tables and put it into the newly released table. When they're finished it will be like we're working with a new legacy system. So, yeah, this editorial is just want I'll need. I'll be watching what insights I can learn on how to understand an "old" database.
Kindest Regards, Rod Connect with me on LinkedIn.