I haven't created many packages, but from what I understand from Microsoft's documentation, you may run across a few problems down the road if you follow this method. Someone please correct me if I'm wrong.
I'm assuming you're creating a major upgrade (since the product code is being changed). Please note, as Stefan said, the package code should always be changed.
Using your example, component C was marked permanent. When you apply the major upgrade, it will leave that file there during the uninstall of the previous version. However, component C is not part of the new cached install. The original cache information from component C would have been removed when the upgrade uninstalled the old version (even though the file remains). If, for some reason, an application or the installer itself needs to get information about component C, I don't believe it will work. For example, let's say you would like to get the path location of component C using the Windows Installer automation; it will not be able retrieve information about this component since it is not part of this package. Also, if for some reason you try to repair or reinstall the package (let's say file C was corrupt or deleted), it will not reinstall this file.
If the user is installing your app on a clean computer, you are forcing the user to first install the original package, and then install the upgrade. If you include component C in the upgrade package, the user could use the upgrade package as a full install, rather than having to use the original package followed by the upgrade package.
Since the file is a database, you probably don't want this file to be overwritten with the empty database. You could probably just use some sort of condition that will allow you to bypass installing this file if it already exists.
Again, I'm no expert by any means, so I can't really say for sure. I hope to get some feedback about this issue as well.