...
This part of the data model is newly normalized in the wake of a previous scheme, which copied the DSP Group to the User record as an attribute. Currently we import user and org data from canonical sources, and endeavor we try not to extend the user object (or other imported objects) just to implement business logic.
Business logic can usually be implemented in business rules, UI Actions, script includes, scheduled jobs, and other code. This can make end user reporting and data mining more difficult, but building reporting structure on top of a primarily transactional the existing database is not a good idea, precisely mostly because it:
- wastes space
- encourages denormalization
...
- introduces complexity and
...
- potential
...
- confusion
Imagine 3 fields in different tables all representing the same object type but with slightly different semantics).. Which one do I use? Are they in sync? We already warehouse data with third parties for reporting purposes, and we discourage any attempt attempts to denormalize data (especially in transactional tables) purely for reporting or integration purposes.
Here is example SNow JS for obtaining the correct DSP Group for a given user in the absence of a denormalized field or store proc:
...