Hey techies, many a times it is noticed that for any new enhancement, a developer creates a single TR and includes all the objects related to the enhancement in the same TR.
This may not be an issue considering minor changes or enhancement to the system.
But, consider a small portion of the bigger picture where you have an enhancement, requesting to create a custom database table, modify / create some other object(s) and based on the entries maintained in this table, the functionality of the other object(s) will work.
In such a scenario, if we create a single Transport Request and include both, the custom table creation and the creation / modification of the other object(s) in the same TR, then give a thought to the difficulty that may arise when transporting this TR into Production.
You will have the newly developed custom table into Production (tables entries not maintained yet) and the new logic of the object(s) which completely depend on the entries maintained in the custom table.
Usually in such scenarios, the end users want that the custom table alone be made available to them in Production so that they can maintain the desired entries in the table (the number of entries may run into thousands or more). This may be a time-consuming effort.
If a single TR contains all the objects, then the functionality may not work as desired in production until the user maintains all the entries in the custom table.
So, to avoid any such complications, it is always better to keep the custom table(s) in a TR separate from the other objects so that if need arises, the tables can be moved alone.
