Does it make sense to set up a satellite table for all non-frequently queried fields?

SeanB

Hi,

Coming from the Bubble world, where it is strongly recommended that one sets up a satellite data type to store all the fields of data that are not commonly queries. This is because in Bubble, you cannot choose the fields to return in a database search query — Bubble returns ALL fields during a database search. So to avoid returning records with say, all 100+ fields in a table, a satellite structure is recommended to keep the commonly used fields in one table and the infrequent fields in a satellite table.

My question is that with Xano, since we can control the specific fields of data returned in a database query, is there a need to model the database with a satellite table or should I have all the fields related to my entity in one table, since I can control what to return.

In my specific case, the application involves immigration and this requires collecting a ton of data from applicants/petitioners e.g. details of all their children, all addresses in the last 10 years, details of every visit, you name it. The table could potentially have 100+ fields. So I'm wondering if I should make a satellite data table as I would have in Bubble or should I use a single table because I can precisely control the fields returned in a Xano query without any impact on performance.

In other words, should I maintain a satellite structure like this

…or should I have all the fields related to the entity in one table like this?

Any advice would be appreciated. Thank you in advance.

Sean

Cameron B

Great question! Coming from a world of Bubble, you'll probably want to familiarize yourself with data normalization. Ultimately, the concept is that in our database design, we reduce duplicate data into their own individual tables, records, and fields.

For instance, a list of all addresses in the last 10 years should probably be its own table, where each record is an address with a foreign key to the petitioner table. This also extends to the visit and visit exit dates as well - where they are their own records in a visits table, linked by the same foreign id.

So, to answer your question, the real answer is going to be that you want to separate your data into as many distinct tables as possible to avoid duplicating data, as well as to ensure maintainability. You can absolutely always use an object field to store datatypes like address lists on the petitioner table, but the goal is to separate. Let me know if you have any questions :)

SeanB

Thank you so much, Cameron. This is super helpful. Really appreciate it.