# Frage zu Datenbank Design bei Events (ZenDesk)



## beta20 (30. Okt 2019)

Hallo,

ich habe eine Frage, wie man das datenbanktechnisch löst.

In ZenDesk gibt es verschiedene Events:





						Ticket Audits
					

Developer documentation for products at Zendesk




					developer.zendesk.com
				




Hier auch die API:








						zendesk-java-client/src/main/java/org/zendesk/client/v2/model/events at master · cloudbees-oss/zendesk-java-client
					

A Java client library for interacting with Zendesk - zendesk-java-client/src/main/java/org/zendesk/client/v2/model/events at master · cloudbees-oss/zendesk-java-client




					github.com
				




Meine Frage ist nun, ob für jede Eventart in der Datenbank eine entsprechende Tabelle angelegt wird oder wie man das löst?

Danke für die Hilfe


----------



## kneitzel (31. Okt 2019)

Also Ich habe erst einmal verstanden, dass Du die Events bekommst und dann in einer Datenbank speichern möchtest.

Hier sehe ich erst einmal viele Möglichkeiten. Welche Möglichkeit Dir am besten gefällt und welche Du bevorzugst, musst Du Überlegen.

a) Man kann das alles natürlich in einer Tabelle handhaben. Die einzelnen, unterschiedlichen Attribute speichert man dann z.B. codiert in ein Feld der Tabelle (z.B. als XML).

b) Du kannst es mit zwei Tabellen machen: In einer Tabelle kommt das eigentliche Event und dann in der zweiten Tabelle die Attribute des Events. (Also Referenz auf ein Event, AttributName, AttributWert) wobei der Wert auch codiert sein muss, denn es gibt z.B. List<long> und so ... )

c) Wir erweitern b) mit einer Tabelle für die vorhandenen Attribute, womit dann nicht mehr AttributNamen mehrfach genannt werden und Umbenennungen z.B. schwer werden.

d) Wir c) noch um eine Tabelle, was für Events es überhaupt gibt. Die Attribute geben dann z.B. an, zu welchem Attribut sie gehören. (Dann ist das entweder eine zu 1:n Beziehung, so dass Attributname nicht mehr unique oder es ist eben eine n:m Beziehung, dann können mehrere Events das gleiche Attribut haben.

e) Das lässt sich dann auch auch noch so erweitern, dass man zu Attributen noch einen Typ dazu gibt. Die Speicherung von Werte erfolgt dann entweder codiert oder es gibt mehrere Tabellen um eben unterschiedliche Typen zu speichern.

...

Oder man baut tatsächlich für jedes Event eine Tabelle - dann hat man für jedes Event eine eigene Entity.

Was man hier gerne haben möchte, liegt am Bedarf. Da hier nichts dynamisch geändert werden muss, würde ich ggf. tatsächlich zu der letzten oder ersten Variante greifen. Das ist abhängig davon, was ich damit machen will. Muss ich damit wirklich arbeiten, dann wird es letztere. Denn dann macht auch die entsprechende Klasse viel Sinn. Wenn es nur um eine reine Anzeige geht und damit nicht viel passiert, dann reicht durchaus eine der ersten Varianten. Zu sehr würde ich das aber nicht aufbohren. Das wäre nur notwendig, wenn das System ganz dynamisch sein muss und z.B. jederzeit weitere Eventsourcen hinzu kommen können, die ich auch speichern können will.

Also musst Du Dir überlegen, wie Du es gerne hättest


----------

