using same table for multiple features a bad coupling?

Question

We are migrating a template that was a mere questions array questions

[
  {
    type:text,
    name:first,
    value:What is our name
  },{
    type:radio,
    name:favourite fruits,
    value:[
      {banana},
      {apple},
      {pears}
    ]
  }
]

to a library like SurveyJS (this Json is complex, can maintain pages of questions with images and nested questions) to create a surveyJSON for one of our features (say doctor notes). Initially, we added the surveyJson column next to the questions array of that template.

Our architect said: what if tomorrow, our patient survey want to use the same template that is created for the note? By adding the surveyJS template into the notetempate table, we have not made it generic.

Ok, So we created a SurveyJSTemplate table that will now hold all templates in a generic way ie. if you have the templateID, you can use the template regardless if the feature is Notes, PatientSurvey etc.

Seems generic to me but with one concern now: The issue I have with this "lets make it generic" is that now, my data is not close to a obect oreinted approach. Before, I would have to pull my NoteTable data into a noteTemplate object and then do noteTemplate.getTemplate() which would give me my surveyJson data. Now, I would have to save the primary key of the templateID in to the NoteTemplate table and query the SurveyJSTemplate table. My service class is merely a data loading class.

Second issue I have with this is that if 5 features now all query the surveyJSTemplate table for their templates, any future migration, alter etc will impact 5 features. If I had maintained the SurveyJson into the NoteTemplate table (and other features maintain their jsons in their table) as eariler, there would be no such coupling.

I believe now that for the sake of "everyone can use everyone' template", there is a stronger couplying between all features that use template.

The only defense I find in this approach is that generally, User table is aso something all features uses but no one complains about strong coupling. So am I overthining the strong coupling caused by the SurveyJSTemplate?

Answer 1

So this is how i interpret your question.

Your SQL tables.

Before :

Note
 Id
 Q1
 Q2
 Q3
 surveyJSTemplateData 

After

Note
 Id
 Q1
 Q2
 Q3
 surveyTemplateId

SurveyTemplates
 Id
 Data

Your object:

noteTemplate
  Q1
  Q2
  Q3
  surveyJSTemplateData 
  getTemplate()
  {
     return surveyJSTemplateData 
  }

Seems to me that this object can be populated by a single select in both cases

Select * from Note left join SurveyTemplates st on note.surveyTemplateId = st.Id

Now you do have the issue that a reused surveyTemplate thats changed, will affect multiple noteTemplates, but this is desirable behaviour where a template is reused and can be avoided by simply making a second template.

There isn't really a coupling issue here, I think you might be using the term in a non-standard way?

Perhaps you could argue that if the goal is to replace the old style template with the new style, then your plan will be to remove all the Q1, Q2 etc fields from the Note table until you are just left with Id and SurveyJSTemplateData. In which case adding the second table now is wrong, because if you do that and remove the question columns then you are left with the unusual

Note
  Id
  surveyTemplateId

SurveyTemplates
  Id
  Data

Which obviously simplifies to a single table.