Hi @OAldrich -depending on how many workbooks depend on that dataset- a feature that may help you in that process is the dataset-replace capability. For a given workbook, you can fully repoint it from the original dataset it's using to another distinct dataset as long as you are able to map each column consumed by the workbook. See this -rather old- video about it : https://youtu.be/2cvmQZItCHE

This is valid mostly if you don't have too many workbooks to update, but may help in your process too.

Your current solution is what I call "cheating" as you play on something that could be seen as a weakness in constraints in the tool. What I mean is that by deleting and renaming you get an ID which wasn't supposed to be given to you as it was used in the past (even if you deleted that dataset) and there are even objects depending on it. This process could also break at any time Oracle decide to enforce some constraints and your rename will generate a new ID instead of re-creating the same as the original dataset you deleted.

The answer to your question is the same as "what is the good practice to make changes to a database design".

The solution Philippe mentioned, remapping an existing workbook to the new version of the dataset would be cleaner, because you cut the implicit dependency you currently have: maintain all the existing columns in a dataset exactly as they are, because if you rename one or remove it, you break the existing references and your trick isn't working anymore. Currently you are kind of doing only incremental changes on datasets that should be considered read-only: you can extended them, but not really modify them.

I would say that a good practice would be to have tools in place to evaluate impact analysis when you change a dataset, and then you have to handle the changes.

Is there an API to modify the code of workbooks or dataflows based on the changes you are doing? Yes there are ways to do the job, I just don't believe it is public APIs (yet).

All in all, a dataset should be seen "like" a database, the good practice for database changes and development could work well, even if you don't have the same tools available.

What you ask, and hope that would exist, is the equivalent of EBR in the Oracle database (Edition-based redefinition): the same object exists with multiple structure in parallel because they are different versions, and each application can select the version (the structure) of the object it is using. This feature doesn't exist in OAC, and I wouldn't expect to see it any soon (or never).