Forum Discussion
MelissaDoran
8 years agoQrew Cadet
I had the same problem with jobs (parent/child jobs) as well as customers.
It's a little confusing at first, but I kept all customers in one table and created a relationship customer-customer. This allows for a company to be a parent or subsidiary. I hadn't looked into any of the implications of doing it this way, but maybe someone can come along and tell my why it's not a recommended option? :)
On jobs for example - our form has a 'related jobs tab' you can either assign the parent or view child jobs from the tab.
It's a little confusing at first, but I kept all customers in one table and created a relationship customer-customer. This allows for a company to be a parent or subsidiary. I hadn't looked into any of the implications of doing it this way, but maybe someone can come along and tell my why it's not a recommended option? :)
On jobs for example - our form has a 'related jobs tab' you can either assign the parent or view child jobs from the tab.
- EvanMartinez8 years agoModeratorThat is another way of doing it. From a technical standpoint creating a self referencing table causes some options to no longer be available such as copy master detail buttons. Self referencing tables disable this function and require an entire re-architecture in the future if that is something that becomes needed or requires a custom scripted button.
From an experience standpoint, being in a Care role before this I've just seen a number of customers who caused themselves a great deal of heart ache trying to navigate a self referencing table when it comes to reporting and keeping the flow of their information clean and organized. Self-referencing tables are functional but I usually prefer to break things up into distinct tables to leverage that separation as a tool. Also long term it helps to keep the tables from individually growing too large as the data is naturally broken up. - MelissaDoran8 years agoQrew CadetThanks for the reply!