Structuring Data Tables and Separating Concerns for Efficiency and Maintainability

In this meeting, the State Changer is seeking guidance on whether to separate a specific object into its own table or to continue storing it in the current way. The State Changer explains that they have multiple tables with a similar format and that each table contains an object with a file array, URL citation, and attribution. They initially tried to handle this by creating individual endpoints for each table, but now they are considering consolidating it into one endpoint or separating it into its own table.


The meeting participant advises that it depends on the context but based on the description given, it would make sense to have a table for file references and an endpoint to upload the file reference. This would allow a separation of concerns and make the logic easier to handle. The participant explains that it is normal to go through the process of discovering the best structure for the application and that changing data structures can be more difficult than changing function stacks. They suggest budgeting for this learning process and suggest separating the object into its own table if it is being used repeatedly in different contexts. The concept of "DRY" (Don't Repeat Yourself) code is introduced and the participant advises that if the repetition is significant and complicated, it may be a sign to separate it into its own structure. The participant concludes by reassuring the State Changer that their intuition is on the right path and it's better to make changes now rather than later.


(Source: Office Hours 7/12/2023 )

State Change Members Can View The Video Here
chris-montgomery-smgTvepind4-unsplash.jpg

View This Video Now

Join State Change Risk-Free