If you have a database schema table with data that multiple applications need access to...
1. Do you create a single Record Type which multiple application use/share? This in my opinion tightly couples your applications.
2. Do you create separate Record Types per application so they can evolve separately? This in my opinion allows each application to evolve it's Record Type independently, and the only tight coupling is the shared database table structure.
What are your thoughts and recommendations on the two approaches?
Discussion posts and replies are publicly visible
What exactly does "need access to" mean?
Both approaches can be valid. My thoughts:
- tight vs. loose coupling
- duplication of data
- uniformity of the data structures
- sharing of record actions
In general, I think that shared data should not be duplicated. But then, the ownership of that data/record/actions/processes needs to sit outside of a project.
Thanks for your reply. By "need access to", I meant the ability to read certain parts of the data (not modify it). i.e. perhaps there are 20 fields/columns, but one application needs to read 5 fields, another 2 fields, and another all 20.I would advocate that a single application owns the data, and contains all the objects which facilitate the modification of that data.
However, if another application needs access to read parts of that same data, they could either:
1. Directly read the table(s) in that applications schema, or2. Receive a copy of that data within their own applications schema (duplication).
If someone went with option 1, then should they also share the original applications Record Type's, or rather create their own?
If you're only interested in reading the data (i.e. not use Record Actions but simply fetch data to be viewed), then I would advocate a domain-based model where a single domain/app "owns" the data and exposes services (WebAPIs) for other Applications to read the data. This decouples the apps, the domain retains ownership for managing the i/o of the data, and makes the separate apps' evolution independent. You'll have to conjure up a versioning approach to manage the evolution of the exposed services to manage changes but that's no more than you would if each app had their own Record type.
If your organization is capable of centralizing organizational ownership and maintenance I recommend to create a single shared record.
If you cannot guarantee that, I recommend to let every project create whatever the need, based on that table.
Another option could be to publish that centralized record by a web API. Then others can fetch data as needed. That adds overhead and you need a good reason for going that way.