Forum Discussion
EvanMartinez
Qrew Elite
Hi Mark,
For scalability in the long term I would recommend planning to build that out so that you have three tables. One for Parent Companies, one for Subsidiaries, and one for Contacts. This way you can have Parent Companies that have Subsidiaries and then both Parent Companies and Subsidiary Company can be related to Contacts. This way you can have a nice flow from Parent Companies to Subsidiary and then from both those tables to Contacts. This keeps all of your data organized and flowing in a way that breaks down the two types of companies you have. Unless you have a use case where a company would be both a Parent and a Subsidiary?
For scalability in the long term I would recommend planning to build that out so that you have three tables. One for Parent Companies, one for Subsidiaries, and one for Contacts. This way you can have Parent Companies that have Subsidiaries and then both Parent Companies and Subsidiary Company can be related to Contacts. This way you can have a nice flow from Parent Companies to Subsidiary and then from both those tables to Contacts. This keeps all of your data organized and flowing in a way that breaks down the two types of companies you have. Unless you have a use case where a company would be both a Parent and a Subsidiary?
MarkComish
7 years agoQrew Assistant Captain
When I view the "Parent Company" on the Subsidiary table it is showing an ID# instead of the Name. When I edit it shows the name, how do I make it show the name when viewing? Sorry for asking things that should be simple._