Application data structure: Dynamic or static

[ztefanie]

As we discussed this already a few times and the topic came up again today, i suggest we decide on, how we want to save our application data:

We can either keep the current, dynamic approach:
Benefits:

• same db table for all applications
• application data structure can change without affecting existing data

We can switch to a more static/defined approach:
Benefits:

• we get closer to a Stammdatenverwaltung, which some Bavarian cities would appreciate
• Some feature would be possible more easily: e.g. grouping application of the same person (or of the same organization) or look up contact of a organization in other applications, e.g. if there is a typo in the email
• Endpoint for Verein360 does not need to deliver labels
• checks for valid data in the backend are easier

Other approach would be to only delete the labels from the JSON in the database and have a key-value i18n like store to map them.

This is the current structure of the data in the JSONs:

This would be my suggestions for a database structure:

Feel free to add pros and cons of each approach and what you prefer.

[f1sh1918]

In my opinion we may wait if we get the frankfurt project or not.
If we make such a big change we should get payed for it or at least wait if a particular functionality requires that and add hours to the estimation there.

For verein360 we can also save translation keys within the jsonStructure instead of the particular values for the labels. We also need some backward compatibility for existing applications for sure but that shouldn't be that difficult

I like your approach and it make sense if we switch to real data management application. It might also make sense to add an attachment table with a file reference and metadata. I probably would move some more information in the dynamicInfo field but that have to be discussed

I think the data migration of existing applications will also be a big issue to tackle