Normalising a Table - Best practice?

[Sheikx800]

Hi All

I have been made aware of a pretty fatal implementation problem with my project. I had a table that was gathering results for a specific business process (lets call it a survey for simplicity). That table ended up holding close to 250 custom entities. I was told by someone in the game recently that this was going to cause me serious problems long-term with app crashes and extremely slow lookups. He has recommended taking the time now to normalise the tables. I dont like the idea of re-inventing the wheel once things are in production so I am working on fixing this now but struggling with implementation. 

I have worked on this and now have the 250 custom entities split up into 7 different tables. The problem I now have is that I am struggling to correctly implement relationships and the model-driven app is now a totally different user experience. To elaborate a little:

I dont know exactly what the relationship implementation for this should look like because its, from my interpretation, supposed to be a 1:1 relationship and they dont exist in Dataverse. I have a single parent record, and then all 6 other tables are child records that simply hold the various entities for that parent record. Those relationships are also configured as parental relationships so that if the parent record is deleted, so are the child records in the 6 other tables. There should realistically be no more than 1 child record in each table for each parent record. While thats not exactly the end of the world if there is, it just adds extra steps to pulling the records and training/making end users aware that only the 'newest' record will be utilised. There is no value or function in having a 1:N relationship here that I can identify, but my fundamental database knowledge is quite intermediate. 

The model-driven app functionality sadly changes significantly now that there is multiple tables to contend with. When it was a single table, I could have a row of tabs along the top to swap between different content areas. For the business process, this was really convenient because the data entry isn't necessarily 'linear'. Being able to half-fill some entities and come back to that tab later had a lot of value. Now that I have child tables, the only way I am AWARE (please someone correct me...) that I can bring in that data is to add sub-grids for those tables. The problem with that method is that when you click + to create a new record in that sub-grid, you need to fill the whole thing out and save it to create the record. You cant leave it half-way and come back. Obviously this is something that can be fixed by refining the business procedures and workflows from a mechanical perspective, but it would be really nice if I didn't have to. The only way I am aware of that I can do this now is by changing to a Canvas app, collecting the data from the user, and then using Patch to populate each table. Its a lot more work than the original, single table, model-driven approach. 

Hoping this all makes sense and someone can give me some guidance with this!

Regards,

Sheik.  

[dpoggemann · Accepted solution]

Hi @Sheikx800 ,

I would be happy to walk through this with you and look at your situation and provide feedback / guidance.  I work a lot with tables and relationships and maybe we could do a call and you would walk me through your details and we can discuss options?

If this sounds good, please send me your information (email / availability) via a private message.

[Sheikx800]

Hi Drew

Thank you for the offer of assistance. We might find the time zone differences a little challenging but if we can line something up it'd be greatly appreciated.

In the meantime - if anyone else has pointers on this, I am happy to hear them! 

[Fubar]

One way around the 'latest' issue is to put a Lookup on the parent record that you populate via Workflow or Flow with the latest Child record created - in so doing you mimic a 1:1 as there is only 1 value allowed in the Lookup (even though it is 1:N and N:1 behind the scenes). 

If you are ending up with lots of 1:1 would probably need to look into if it was necessary etc.

[Sheikx800]

Hi Fubar. This was how I was planning on working it for the Lookup-side of things. Thank you for confirming I am on the right track. I definitely dont have lots of 1:1. Its only this single use case because it's all supposed to be a single data set and doesn't have any real logical basis for being separated other than database limitations. 

If anyone has any ideas on the interface side of things it'd be great. Otherwise I guess I am stuck going with Subgrids. 

Cheers.

[Sheikx800]

Just posting back after getting some much appreciated assistance from @dpoggemann. I am going to try and describe my use case a little better so that it might be of benefit to others.

My concern coming into this was that I had too many entities in a single table. A record in this table basically holds 'responses' a survey and would all be related. All entities are going to be essentially very short choice and text field responses. No lookups. As physical example of this would be an inspection of a supermarket. You check shelving, lighting, pinch zones, foot/trip hazards, etc.. And you need fields for each of these things to say that it was or wasnt checked and to put in notes.  There was no requirement for normalisation because of the data itself.

My concern was coming from the possibility that later on, the size of those records, as they increased, would cause performance issues with the database or the PowerApps themselves. 

Drew's opinion on this was that this is likely an unnecessary concern for a long time to come. @dpoggemann if you have anything extra that you would like to add to further clarify things with more eloquent terminology please do. I would also be interested to read up on that customized solution that you suggested if there is reading material on it. Just for the sake of knowledge rather than implementation thankfully. 🙂 Thanks again!