Denkanstoß bei Speicherung von Genehmigungen

[beta20]

Hallo,

ich möchte gerne nachfragen, ob mein Konzept passt und würde mir gerne Feedback dazu einholen.

Ich habe folgendes Thema. In meiner Software muss der User gewisse Dinge akzeptieren. Angefangen von der AGB / Datenschutzerklärung.
Prinzipiell kann ich dazu ein Flag pro User einbauen "acceptAgb" etc.
Allerdings ist das dann nicht dynamisch. Man hat es ja bspw. bei der DSGVO gesehen, hier hätte ich dann in der DB ein neues Feld erstellen müssen.

Das ganze möchte ich nun dynamischer gestalten, denn ein User kann / muss auch weitere Genehmigungen akzeptieren. Ich möchte nicht für jede weitere Genehmigung nun weitere Felder in der DB erstellen müssen...

Mir schwebt daher folgendes vor:
- Eine Tabelle "Approval" zu erstellen

- ID
- uniqueName (ist dann der Typ der Approval, AGB etc.)
- createDate
- userFK

-> Sprich, wenn es einen Eintrag gibt, dann hat der Nutzer dies bestätigt. "CreateDate" ist dann eben der Zeitpunkt
Ggf. könnte man auch noch eine "ApprovalCategory" erstellen. Diese würde dann uniqueName ersetzen. Man könnte dann später das ganze noch besser auswerten.

ApprovalCategory
- ID
- Name

Approval
- ID
- createDate
- userFK
- approvalCategoryFK

Danke für jegliches Feedback

 

[MoxxiManagarm]

Ja, das ist ein typisches Vorgehen für eine n-n Beziehung. n-n kann Datenbankseitig nicht abgebildet werden, daher wird für n-n Beziehungen immer eine Zwischentabelle eingefügt, damit du 2 n-1 Beziehungen bekommst. Diese Zwischentabelle ist bei dir Approval. User und ApprovalCategory haben die n-n Beziehung, beide Entitites haben jeweils eine n-1 Beziehung zu Approval.

 

[LimDul]

ich sehe erst mal nichts, was dagegen spricht. Ich würde dann aber wenn direkt die zweite Variante machen. Weil irgendwo wirst du ja auch festlegen müssen, welche Approvals dem User vorgelegt werden sollen. Und da kommst ohne die ApprovalCategory schnell in das Problem, dass du die UniqueNames an mehreren Stellen verwalten musst - daher wäre da eine ApprovalCategory sinnvoll.

Das einzige Gegenargument zu dem Konstrukt ist, "Keep it simple". Ist diese technische Lösung wirklich notwendig? Oder baut man hier als technikverliebter Entwickler gerade einen goldenen Henkel, der mehr Aufwand kostet als er in den nächsten Jahren Nutzen bringt. Diese Frage kannst nur du beantworten. Ich sehe bei der Variante das jetzt erst mal nicht, insbesondere da mit Newslettern und Co ich mir gut vorstellen kann, das eine Dynamik der zu pflegenden Approvals sinnvoll ist. Aber diese Frage sollte man sich immer einmal stellen um sicher zu sein, dass man eine angemessene Lösung baut.