Hi all,

 

I have multiple table instances in my solution, for various reasons...

 

some are search or filtering to a portal in a different table, based on a global search field, others are connected to other tables for pulling data into those tables...

 

My Question is... having all these seperate instances of the same table seems a messy and convoluted way forward... is there a way around this?

 

And before anyone mentions it, I know I can create portal filters for searching and filtering related tables.

 

Am I just missing something critical??

 

Steve

 

 

No way to tell. We can't see your file.

Agreed with Bruce, no way to evaluate that without knowing what your solution does and how you're doing it.

 

In principle having multiple TOs per base table is not a problem per se.  Remember that the graph is not an ERD.

For best performance you do want to keep the overall number of interconnected TOs to a minimum and each TO has to serve a purpose.

I'm a believer in "skinny" tables. Only necessary fields. I break up "fat" tables all the time into smaller ones. This kind of normalization seems to lead to faster performance IMHO. Therefore I have a lot of tables. Add TOs to the mix and it's possible to have a hundred (well, not that many thus far)TOs in a solution. However each one is there for a specific reason and operates from a specific context. It makes for a complicated relationship graph so grouping and color coding become important. The graph, it seems, is there to provide an easy to understand graphic interface for the developer. However it can defeat itself and the graphical aspect can become a real hindrance when the relationships multiply. I may be missing something but I feel it could use some improvements.

And how do you manage the creation of the related skinny records?

Bruce, the same ways I would for any record in a table. I don't understand how the number of fields in a table influences how related records are created. For example, I have separate tables for Social Insurance Number (Canada) and Social Security Number (US). Separate tables for addresses and mobile phone numbers. They all get entered in a layout based on Contacts, so there's no problem.

Off-loading to 1:1 tables is smart practice.  It means the lesser-used fields are not downloaded from Server.  With Allow Creation on, just placing the side-table's fields onto the layout is all that is needed.  And you know this, Bruce, so I am interested where you are going with it.