When to create a child/sub table.
It has been mentioned in this forum about when to create a child/sub table. One way is if you find your self adding a prefix or suffix to your fields that store similar data. Like phone1 and phone2 or employee1 and employee2. Or in my case rdAtm or fAtm or mAtm.
As you can see I fell into the trap. I wanted to find how many rounds were attempted by all riders then by female or male. Which means I needed to create 16 formula fields. Which means that 16 formula fields now run for each record. Luckily it was on a table with not too many records. But we can do better.
So a new child table was added:
The redesign reduced the formula fields to 8 per record, the view only shows 4.
I have to put a plug in for Ninext again when doing redesigns. I would not have been able to find all of links that my old fields were attached to without it.
Here is what Ninext tells me:
And it links me to the formulas so I can edit them. Then I can safely delete the old fields. I've done redesigns where I've had to clear up 25 links.
Thanks .
What are some of your learning moments?
4 replies
-
Ah Fred - I think at times we all fall into this trap at times.
It is dead obvious when you have say an invoice header and you want to add multiple product items to the body. but it is not always that clear at the time.
I need to revisit my job bags - Traditionally, following on from an old software./methods in that no matter how many production items a client placed with us. we would always create individual jobs so they could follow the product around the factory. Yet - because of the huge advances and advantages that Ninox brings. I can see great opportunities to have one main job header and several child sub jobs attached as operators only need to view the elements that are assigned to them.
My issue is - do i accept that i should leave previous table history (24,000 + jobs) should stay as it is and create a new table moving forward for (multiple jobs) or do I modify the existing table format and try to dovetail the data into a split header and create a single child form. There is nothing really to link the jobs back to header.
it is one for me to cogitate over as both methods involve some serious reworking or creating all the reports / printouts etc.. and of course i keep putting this off
-
Maybe create a "new" production table with the new format. Leave the old stuff alone, and just move forward with the new. It will mean modifying print layouts but better than creating all new ones.
It will also mean creating a work flow that can access the old data when needed.
Enjoy the process.
-
Yes i though so too. but other alterntaive is to retire and leave it to someone else to sort
-
LOL
. That is also a very good choice.
-
Content aside
- 19 hrs agoLast active
- 4Replies
- 41Views
-
2
Following