Posted: 2 Dec 2015 23:15 EST Last activity: 11 Dec 2015 13:26 EST
Why 'New Application' wizard generates separate Work & History tables for FW and Implementation Layers
Let's say if we start a project with "Application Structure" as 'Framework and Implementation', why is that the New Application wizard generates 2 separate Work tables (Clones of pc_work) and 2 separate WorkHistory tables (Clones of pc_history_work)?
Consider the following scenarios (Let's say all Work Types of FW and Implementation layers are sharing same work table mapped to their respective Class Groups) :
1. Assuming that Developers will creates cases while unit testing in FW application, we will never have to isolate these cases to that of the Implementation App cases physically in 2 different Work Tables. And also we never have to isolate history of cases created from FW and Impl layers into 2 separate tables.
(Since multiple classes can be mapped to one single table using 'Database Table' record, 'New Application' wizard should ideally be doing this)
2. Assuming that Developers will always access FW layer to define reusable records and not even a single case is created in that layer, clearly we do not need a table at all to which a FW Class Group or FW Work Classes need to be mapped to.
Majority times History tables are self sufficient and might not have new properties Optimized for reporting purposes. So there may not be maintenance overhead for history tables while it's still unnecessary to have 2 separate history tables. But for Work Tables, by chance, if someone considers this (New Applicaiton Wizard way) as a recommended approach, they will end-up maintaining 2 case tables, adding the over-head of promoting schema changes across QA, Staging and PROD environments (If the database user have restrictions on DDL operations the zip/jar file we import into QA/Staging/PROD won't promote schema changes automatically, and we end up supplying scripts to DBA's on 2 case tables instead of just 1).
Thanks Chunzhi for sharing your thoughts. We followed same approach and cleaned up the unwanted tables as well. Just shared this so that it might be helpful for others. It will be nice if we can pass on this as a suggestion to the concerned SME for consideration (possible enhancement)
I was reviewing your post and I wanted to reach out and see if you would like us to open an Enhancement Request for you? And if so, could you please provide us with details that we can submit on your behalf?