Whatever naming scheme works for you and your fellow DBA's, use that. Just be consistent across your enterprise. It doesn't matter what you call your PDBs and CDBs just so long as everyone on the team knows the naming scheme and it works for all parties.

Also keep in mind that your applications don't need to know what the naming scheme is. You can, and probably should, create services. Your applications connect to the service and the service points it to the correct PDB.

If I could offer one suggestion it would be that I would not name a PDB to have the CDB name in it. The reason is simple...upgrades. I'm currently upgrading many PDBs from 12.1.0.2 to 19.3. To do that, I created a 19.3 CDB. I unplug the 12.1.0.2 PDB from the 12.1.0.2 CDB and plug it into the 19.3 CDB and upgrade the PDB. If I had the PDB named after its CDB, the PDB would be improperly named on plug-in. Upgrades is just one example. As you work with Multitenant more, you may come up with other reasons to move PDBs from one CDB to another. Remember that the P in PDB means Pluggable. They are designed to be unplugged and moved to other PDBs.

And it is this moving of a PDB from one CDB to another that is a big reason why I use services. My applications know the service name, but as the DBA, I can move the PDB and even change the PDB name during the move (Yes...I know this PDB rename does negate my earlier point in the previous chapter) but the service name stays the same.

To me, I would name the PDBs with something meaningful to the application(s) that PDB supports. I would name the CDB something meaningful. But I do not ties the PDB name to the CDB name or vice versa. Maybe that's just me.

Cheers,
Brian