SQL /[PHP] Projekt: HTML Formulare "zusammen klicken" & dynamisch speichern

[derBobby]

Hallo zusammen!

Momentan arbeite ich an einem kleinen Projekt, das benotet werden wird. Ein CMS kann ich daher nicht einfach nehmen Ich hatte Probleme den Titel passend zu formulieren, entschuldigt falls er etwas irreführend ist!

Ich fang daher einfach mal mit einer Beschreibung an, was ich vorhabe:

Eine gemeinnützige Jugendarbeit möchte Online-Anmeldungen für verschiedene Freizeiten ermöglichen. Jede Freizeit frägt verschiedene Daten ab. Das Zeltlager für Kinder möchte zum Beispiel Lebensmittelunverträglichenkeiten und Allergien wissen, da die Kinder in dem Alter das selbst noch nicht selbst verstehen und wissen. Die Freizeit für Teenager frägt diese Dinge nicht ab. Da jederzeit weitere Freizeitformen hinzukommen können, die dann vielleicht Zimmerwünsche etc. abfragen, wäre es unfein für jede eine eigene Tabelle, mit den benötigten Spalten, anzulegen.

Eine Möglichkeit, die mir zur Lösung gekommen ist, wäre die allgemeinen übereinstimmenden Informationen normal in Spalten abzulegen und die speziellen Informationen in einer Spalte serialisiert abzulegen.

Meine Fragen dazu:

- Welchen Weg, die Informationen zu speichern, würdet ihr zur Umsetzung empfehlen? Gibt es Alternativen?
- Wie könnte man es dem Veranstalter ermöglichen verschiedene Felder für sein spezielles Anmelde-Formulare zu erstellen ("zusammen zu klicken")?

Ich hoffe auf gute Ideen!

Gruß und Dank
derBobby

 

[bandit600]

Hi derBobby

Leider fehlt noch ne Menge an Hintergrund um eine wirklich fundamendierte Empfehlung zu schreiben, aber ich könnte mir folgendes mit HTML,PHP und SQL (das ist aus meiner Sicht schon die beste Wahl) vorstellen:

[HTML mit PHP(und/oder JavaScript)]
Eine Anmeldung, bei der man im ersten Schritt eines der verschiedenen "Events" auswählen kann und anschließend auf der eigentlichen Anmelde-Seite die entsprechenden eventspezifischen Fragen bekommt und allgemeine Angaben zur Person machen muss.

[SQL]
Alles in allem steht und fällt deine Seite mit einer guten Aufstellung der Datenbankstruktur.

du brauchst mehrere Tabelle:

Event(eventID,Datum,Name)
Fragen(frageID, Text)
Zuordnung_Event_Fragen(eventID,frageID)
Teilnehmer(teilnehmerID,Name,Straße,usw)
Zuordnung_Teilnehmer_Event(teilnehmerID,eventID)
Teilnehmer_Fragen(teilnehmerID,frageID,Antwort)

Das ganze kann man dann alles noch bissl erweitern und für den Veranstalter schön auswerten.

Gruß bandit600

PS: Weiterhin könnte man dann noch eine "versteckte" Seite für den Veranstalter machen, auf welcher er Fragen zu den Events und die Events selbst anlegen und editieren kann.

 

[derBobby]

Danke für das Eingebrachte!

Mit den zwei Schritten, zwecks Auswahl einer Freizeit und des Anmeldeformulars, hast du im Prinzip ins schwarze getroffen.

Der Vorschlag mit den vielen Tabellen kann ich im Prinzip nachvollziehen, jedoch schreckt mich hier ein wenig die Komplexität ab. Gewiss ist diese minimal im Vergleich zu dem was einem sonst so begegnet, jedoch bin ich bisher von einer eher "schnuckeligen" Datenbank ausgegangen.

Was ich anscheinend nicht ganz korrekt rüberbringen konnte ist, dass eine handvoll ehrenamtliche "Veranstalter", sprich Freizeitleiter, aus der Jugendarbeit sich für ihre Freizeit ein Anmeldeformular zusammenklicken können sollen. Hast du dazu auch eine Idee? Meine wäre, dass ebenfalls in mehreren Schritten ein Element hinzugefügt werden kann. In Schritt eins kann aus einem HTML-Dropdown ein Elementtyp ausgewählt werden. In Schritt zwei bekommt es eine Bezeichnung für die DB und die Frage an den Anmeldenden. Schritt drei fügt diesen dann endgültig ein.

Ich glaube ich habe gerade meine 150 Stunden Aufwand für das Projekt verdoppelt. :X

 

[bandit600]

AW: [SQL]/[PHP] Projekt: HTML Formulare "zusammen klicken" & dynamisch speichern

mach dir mal wegen den paar Tabellen keinen Kopf, man könnte das auch auf 2 Tabellen eindampfen aber da stehen dir deutlich weniger Möglichkeiten zur Verfügung was du damit anstellen kannst und redundante Daten kommen auch noch in die Datenbank.

Den zeitlichen Rahmen von 150 Stunden solltest du aus meiner Sicht für das bisher beschriebene auch noch locker schaffen.

Allerdings würde ich Dir mehr als empfehlen den Zugriff für die Freizeitleiter mittels eines Logins zu beschränken, immerhin sammelst du mit deiner Anwendung dann personenbezogene Daten, die nicht jedem zugänglich sein sollten.

Damit benötigst du allerdings noch mindestens 1 Tabelle mehr und der zeitliche Rahmen wird dann sicherlich auch gesprengt - das ist aber wirklich notwendig und sinnvoll.



Bezüglich der Erstellung des Event und der damit verbundenen Fragenliste gibt es mehrere Möglichkeiten:

1) einstufig: man legt ein Event an bei dem man alle Fragen angezeigt bekommt und aus diesen dann die wichtigen Fragen auswählt bzw weitere hinzufügt. Das wird aus Sicht der Benutzbarkeit über kurz oder lang unübersichtlich
2) mehrstufig, wie von dir beschrieben. Allerdings würde ich dann die Fragen gernerell irgendwie versuchen zu kategorisieren (was wahrscheinlich nicht ganz einfach wird) und die Kategorien nicht mittels Dropdown sondern mittels Checkliste auswählen
also z.B.
2.1) EventName und weiteres eingeben und die Kategorien auswählen
2.2) Fragen aus Kategorien auswählen und ggf weitere hinzufügen und dann das Event anlegen

Gruß bandit600

 

[derBobby]

Also eine Accountverwaltung habe ich bereits vollständig umgesetzt. Die Sachen wurden in einer ersten Arbeit erledigt. Jetzt geht es also "nur" um das Erstellen der Anmeldeformulare und die Möglichkeit dieses auszufüllen. Da werde ich dann das mehrstufige Modell umsetzen. Wobei ich gerade immernoch der Meinung bin, dass das mehr als 150 Stunden werden! Ich bin gespannt!

 

[bandit600]

Na denn viel Spaß. Kann man sich die Seite irgendwo mal anschauen?

 

[derBobby]

Aktuell ist das viel zu sehr Baustelle, als dass man sich da irgendetwas anschauen kann. Wird momentan eh noch lokal mit XAMPP entwickelt. Bestimmt kommen von mir noch ein paar Fragen deswegen. Wenn ich weitere 130 Stunden reingehängt habe, kann man da vielleicht mal über Einblicke reden!

 

[benneq]

Ich gehe davon aus, dass du eine relationale Datenbank benutz, richtig?

Das mit dem "Zusammenklicken" der Formulare ist eine heikle/nervige/blöde Angelegenheit.
Prinzipiell hast du 2 Möglichkeiten zur Umsetzung: Über DB-Tabellen oder eben über serialisierte Strings.

Also ab zum eigentlichen Problem:
- es gibt prinzipiell eine unendlich große Anzahl von Formularfeldern (z.B. einfacher String, ein Datum, ein Integer, eine positive Kommazahl mit 2 Nachkommastellen ... aber genau so denkbar wäre eine Liste aus Tupeln von Uhrzeit + String, genau so wie geordnete und ungeordnete Listen)

Dann hast du nun folgende Optionen:
1a.: Du bietest einen eingeschränkten Satz an Feldern an, die lassen sich schön einfach hardcoden.
1b.: Du nimmst den generischen Ansatz. D.h. der User wird mit Auswahlmöglichkeiten erschlagen. Z.b. "ich möchte ein Reihe von Checkboxen, am Ende muss eine gerade Anzahl an Boxen angehakt sein, aber es dürfen nie 3 aufeinanderfolgende Checkboxen angehakt sein". Klingt auf den ersten Blick 'unnötig', aber damit ließe sich am Ende quasi jedes beliebige Formular umsetzen.
(Mein Tipp: Variante 1a. Die grundlegenden Typen sind schnell geschrieben und sollten für 95% der Fälle ausreichen und die 1-2 Sonderwünsche lassen sich auch flux umsetzen)

2a.: Wenn du eine feste Anzahl an Feldtypen hast, könntest du für jeden eine eigene Tabelle in der DB anlegen. Das hätte Vorteile in Bezug auf Typisierung und Validierung der Daten. D.h. auch eine Änderung eines Feldtyps wäre ohne großes Parsen möglich.
2b.: Dynamische Serialisierung der Feldtypen. Zuerst wählt man sich eine wohldefinierte Formatierung der Daten. Als erstes sollten einem hier JSON und XML in den Kopf kommen. Ich nehme einfach JSON, da es kompakter ist.
Bsp. 1: Ein einfacher String:

{
  name: "abgiu032jpn492b9",
  type: "string",
  description: "Vorname:"
}

"name" legt quasi den eindeutigen Namen des Feldes fest. Durch "type" weißt du, wie du die Daten zu (de)serialisieren hast. Und "description" steht dann im Formular vor dem Input-Feld. Hinweis: "name" sollte nicht vom User festgelegt werden, sondern wird beim Erstellen des Formulars generiert.
Bsp. 2: Array von Datumsangaben (der User legt die Anzahl bei der Erstellung des Formulars fest):

{
  name: "rht9h0tpwjng",
  type: "date",
  count: 5,
  description: "Wann darf ihr Kind Schokolade essen:"
}

"name" ist wieder eine Art UUID. "type" sagt dir wieder, wie du zu (de)serialisieren hast. "count" sagt dir, dass es ein array von 5 Elementen dieses Typs ist. etc.
Hier wäre eine NoSQL-Datenbank natürlich super ;-)

Das lässt sich natürlich auch anders umsetzen, das war jetzt nur ein erster spontaner Einfall und (hoffentlich) Denkanstoß. Ein komplettes Formular könnte dann in der DB so aussehen:

[
{
  name: "abgiu032jpn492b9",
  type: "string",
  description: "Vorname:"
},
{
  name: "nu943ubgn94tgh",
  type: "string",
  description: "Nachname:"
},
{
  name: "f37irsbiung34iubi",
  type: "date",
  description: "Geburtstag:"
},
{
  name: "wng2932oprnwg",
  type: "string",
  delimiter: ","
  description: "Allergien (durch Komma trennen):"
},
{
  name: "kfjhoj4o4kwtjngo",
  type: "time",
  description: "Schlafengehzeit (unter der Woche):"
},
{
  name: "u40objtbgw9inn",
  type: "time",
  description: "Schlafengehzeit (am Wochenende):"
},
{
  name: "41z08ipjetsewnlg",
  type: "string",
  count: 3,
  description: "Top 3 Superhelden:"
},
{
  name: "fhogwngsdljdjd",
  type: "boolean",
  description: "Veganer Stufe 5:"
}
]

Damit hätten wir nun folgendes Formular generiert:
Text-Input, Text-Input, Datum-Input, Text-Input (die Komma separierte Liste, könnte man dank des "delimiter" auf der Serverseite dann auch schön speichern, aber geht natürlich auch als einfacher String, aber dann ist der delimiter unnötig), Uhrzeit-Input, Uhrzeit-Input, 3 zusammengehörende Text-Inputs, eine Checkbox.
Also da hast du Spielraum ohne Ende, wenn du willst. Aber es bleibt einfach und übersichtlich. Erlaubt aber halt auch keine unendliche Dynamik.

Für die Datenbank würde ich allerdings ein 5-spaltiges Layout wählen:
- name (unique) <- da würde es natürlich auch eine ID mit autoincrement tun
- formular_id (foreign key)
- type (enum oder varchar)
- description (varchar)
- sonstiges (z.B. count, max-length, delimiter, etc.)

Wenn die Eltern dann was eingetragen haben kommt das in eine separate Tabelle. Die könnte so aussehen:
- field (foreign key auf das Feld (aus der Tabelle zuvor))
- value (varchar oder gar 'text'. anders lassen sich sonst nicht alle möglichen Typen und Serialisierungen speichern)

Hier und da muss dann wohl noch eine 'user_id' mit eingefügt werden, aber das ist ja das geringere Problem.


Grütze,
benneque

 

[derBobby]

Hallo,

also die Datenbank habe ich jetzt mal wie folgt aufgebaut. Meinungen, Verbesserungsvorschläge?



@benneque: Mit Typen von Formularfeldern habe ich die verschiedenen Input-Typen gemeint. Textfield, Selectbutton, Checkboxen etc. Die Inhalte, was z.B. in Textfields eingetragen wird, die würde ich momentan nicht einschränken. Das überfordert den Anwender im ersten Moment vielleicht ein wenig. Wenn die Arbeit abgegeben wurde und das Ding irgendwann von besagtem Verein eingesetzt werden soll, dann kann ich mit der Form_validation Klasse des verwendeten Frameworks die Eingaben zusätzlich einschränken. Aufgrund der zeitlichen Einschränkung muss ich darauf vorerst verzichten und mich auf die Kernfunktion konzentrieren. Außerdem muss ich gestehen, dass ich gerade Gedanklich nicht ganz mit deinen Vorschlägen 1a,b & 2a,b mitkomme :/ Da muss ich mir noch mal Zeit nehmen, mich reinzudenken.

Gruß und Dank
derBobby

 

[benneq]

Ich persönlich würde auf jeden Fall die Many2Many Beziehungen 'form <-> question' und 'form <-> event' entfernen. Das macht das Handling einfacher:
- 2 Tabellen weniger
- answerdependency würde diese blöde Abhängigkeit zu 'event' verlieren, die nebenbei gesagt völlig falsch ist! answerdependency müsste (wenn man es denn wollte) von 'formevent' abhängen.

Falls die 'form <-> question' Many2Many-Relation bestehen bleiben soll, dann ist noch ein Fehler im Aufbau: Dann muss sich answerdependency nämlich auf 'questionform' beziehen. D.h. nicht zwangsläufig - ich würde für diesen Fall eigentlich lieber Folgendes vorschlagen:

Anders gesagt:
Wenn du dein Datenmodell - so wie du es aufgemalt hast - beibehalten willst, dann brauchst du Folgendes um eine Antwort (= answerdependency) EINDEUTIG zuzuordnen:
- event
- form
- question
Weil: Durch ein Event allein weißt du nicht welches Form gemeint ist. Durch eine Question allein weißt du nicht welches Form gemeint ist. Durch ein Form allein weißt du nicht welches Event gemeint ist und auch nicht welche Questions enthalten sind.
Du brauchst also alle 3 Angaben, indem du dich entweder auf die 3 Tabellen einzeln beziehst oder direkt auf die beiden Verknüpfungstabellen: 'formevent' und 'questionform'.


Zusätzlich versteh ich die Verknüpfung 'answerdependency <-> answer' nicht. Die besagt: "Unterschiedliche User können zu einer(!) Frage, die zu unterschiedlichen Formularen gehören kann, welche wiederum zu unterschiedlichen Events gehören können, ..." (<- dieser Mist entsteht durch die ganzen Many2Many Beziehungen) "... dieselbe(!!!) Antwort geben" (d.h. gleiche answer_id).
Ohne die ganzen Many2Many Beziehungen hieße der Satz einfach nur: "Unterschiedliche Nutzer können zu einer(!) Frage dieselbe(!!!) Antwort geben". (Denn: Ohne die Many2Many Beziehungen steht direkt fest, dass sich diese Frage nur auf ein(!) Formular beziehen kann. Und dieses Formular gehört auch nur einem(!) Event an. Also sind diese ganzen extra Infos unnötig).
Dennoch: Völliger Unsinn, wenn du mich fragst. Speicher das Textfeld mit in der ''answerdependency" Tabelle und benenn sie in "answer" um. Daraus ergäbe sich dann der - meiner Meinung nach - korrekte Satz: "Unterschiedliche Nutzer können zu einer Frage eine Antwort geben."



Das mit 1a,b & 2a,b bezieht sich einzig und allein darauf, WIE die verschiedenen 'questions' in der Datenbank abgelegt werden könnten.
Wenn du die beiden Many2Many Relationen entfernst, wäre mein Plan auch deutlich einfacher umzusetzen ^^.

Was ich damit sagen will ist: Eine 'question' muss eindeutig identifizierbar sein (id), muss einen Fragetext haben (text), aber muss eben auch einen Typ und sonstige Eigenschaften definieren. Den Typ vorzugsweise als Enum - wenn möglich - und die sonstigen Eigenschaften entweder als Varchar oder als Key-Value Tabelle mit einer Many2One Verknüpfung zur 'question' Tabelle.

 

[derBobby]

• Ein Benutzer kann viele Forms erstellen.
• Ein Benutzer kann viele Events erstellen.
• Einem Event muss eine Form zugeordnet werden.
• Eine Form kann vielen Events zugeordnet werden. (Unklar gewesen, kann das sein?)
• Eine Frage muss einer Form zugeordnet werden.
• Einer Form können viele Fragen zugeordnet werden.

Hast du das so verstanden? Nur damit wir mal auf Pseudo-Code-Ebene auf einen Nenner kommen! Ein überarbeitetes Bild kommt dann auch gleich.



//EDIT: Um eine Antwort eindeutig zu identifizieren fehlt noch der Account. Ich habe Veranstalter und normale Benutzer in einer Account-Tabelle, die mit unterschiedlichen Statuswerten identifiziert werden.

 

[bandit600]

Hallo zusammen,

auch wenns vllt nicht gerade konstruktiv ist, aber ich finde den gewählten Ansatz von "benneque" im wesentlichen zu kompliziert und kann diesem Ansatz ebenfalls nicht bis ins letzte Detail folgen!

Als kleine Anregung will ich aber noch mal die Frage in dem Raum werfen, ob man eine Frage nicht auch mehreren Formularen zuordnen kann?

Gruß bandit600

 

[derBobby]

Nein, eine Frage ist genau einem Formular zugeordnet. Würde ein Veranstalter eine Frage aus "seinem" Formular ändern, so würde sich die Frage im Formular eines jeden anderen Veranstelters ebenfalls ändern.

 

[benneq]

Also dein neues Diagramm besagt nun:

1.:
- Ein Event kann beliebig vielen Benutzern gehören
- Ein Event hat genau ein Formular
- Ein Formular gehört einem Benutzer
Das wirkt irgendwie unschön, bzw. in der Modellierung nicht eindeutig. Fallbeispiel:
1. User A erstellt Event E
2. User A lädt User B zum Event ein
3. Wer darf nun das Formular gestalten? Bzw. wenn einer es macht, kann es niemand anders mehr ändern?
Das Einzige was mir dazu einfällt: User A kann einen User bestimmen, der die Kontrolle über das Formular hat. Aber dann hätte er auch automatisch die Kontrolle über alle anderen Formulare mit derselben ID.
Warum sollte es überhaupt für mehrere Events ein- und dasselbe Formular geben? Von den Benutzerrechten ist das nämlich Humbug. ... und wer hat überhaupt das Recht die Person zu ändern, die die Rechte am Formular hat?
Und nicht nur das, auch die Fragen/Antworten sind für die Tonne, wenn sich für eine Wiederholung eines Events das Formular ändert.

Bsp:
Jahr 2012: Event "Kinderfreizeit X" wird angelegt mit passendem Formular. 50 Leute tragen ihre Daten ein.
Jahr 2013: Event "Kinderfreizeit X" finder wieder statt, also nimmt man dasselbe Formular (= selbe ID). Dann stellt man fest, dass eine alte Angabe unnötig ist und dafür eine neue hinzukommt.
Ergebnis: Die Daten, die 2012 eingegeben wurden, passen nicht mehr wirklich zum Formular.

Mein Vorschlag:
Pro Event ein neues Formular (d.h. die form-Tabelle würde rausfliegen, weil man dann auch direkt die questions mit dem event verbinden könnte). Da kannst du ja 'ne simple Option einbauen, um das Formular von vor x Jahren zu kopieren, damit man es anpassen kann.






2.:
- Ein Formular kann beliebig viele Fragen haben
- Eine Antwort ist definiert durch: Frage, Formular, Event
Das Formular ist hier unnötig, da das angegebene Event nur genau ein Formular haben kann



Abgesehen davon sieht es nun schon weeeesentlich besser aus als vorher Überdenke die beiden Punkte noch mal



EDIT: Die Userverwaltung mit allen in einer Tabelle ist schon richtig so. Mit mehreren Tabellen könnte folgendes passieren: Ein username wird doppelt vergeben an einen Normalo und einen Veranstalter Das müsste man sonst mit unschönen Constraints beheben, aber man hätte dadurch keine Vorteile, sondern eher Nachteile, weil man in der Software noch mehr Code schreiben müsste (oder alternativ mehr Code in der Datenbank).
Außerdem müsste man dann für jede Benutzergruppe eine neue Tabelle erstellen, ne ne ne. Dann lieber - wie du es schon hast - mit ManyToOne. (Den Statuswert speichert man dann entweder als MySQL ENUM oder als Verknüpfung zu einer zweiten Tabelle. Varchar oder Int wäre blöd, weil es dann Werte geben kann, die gar nicht zulässig sind).
In größeren Projekten löst man es meist mit einer ManyToMany Beziehung (user <-> gruppe). [Z.B. für: User X ist Admin für Bereich Y und Admin für Bereich Z, aber für alle anderen Bereiche nur normaler User.] Dann evtl. Gruppen mit Rechtevererbung in der DB oder in Software, wie an es halt braucht.



EDIT2: Denke daran für die Fragen eine zusätzliches Spalte einzuführen, damit die Fragen auch genau in der Reihenfolge ausgegeben werden, wie du sie willst. Denn: Wenn du ein normales SELECT ... machst (ohne ORDER BY), ist die Reihenfolge der ausgegebenen Reihen beliebig. Auch wenn es im Normalfall funktioniert und in 99,9% der Fälle das richtige Ergebnis geben wird, so ist die Reihenfolge nicht wohldefiniert und muss erzwungen werden! Die einfachste Möglichkeit wäre natürlich ORDER BY id zu nehmen, aber dann wird's schwierig wenn man nachträglich die Reihenfolge ändern möchte. Man müsste dann alle Einträge aus der DB löschen und neu schreiben.

 

[derBobby]

- Ein Event kann beliebig vielen Benutzern gehören Check!
- Ein Event hat genau ein Formular Check!
- Ein Formular gehört einem Benutzer Check!

Das wirkt irgendwie unschön, bzw. in der Modellierung nicht eindeutig. Fallbeispiel:
1. User A erstellt Event E
2. User A lädt User B zum Event ein
3. Wer darf nun das Formular gestalten? Bzw. wenn einer es macht, kann es niemand anders mehr ändern?
Das Einzige was mir dazu einfällt: User A kann einen User bestimmen, der die Kontrolle über das Formular hat. Aber dann hätte er auch automatisch die Kontrolle über alle anderen Formulare mit derselben ID.
Warum sollte es überhaupt für mehrere Events ein- und dasselbe Formular geben? Von den Benutzerrechten ist das nämlich Humbug. ... und wer hat überhaupt das Recht die Person zu ändern, die die Rechte am Formular hat?
Und nicht nur das, auch die Fragen/Antworten sind für die Tonne, wenn sich für eine Wiederholung eines Events das Formular ändert.

Nur der Ersteller (=Eigentümer) des Formulars darf dieses ändern. In deinem Fall "User A". Der eingeladene "User B" soll ja das Formular nicht ändern etc., sondern dieses ausfüllen, damit die Informationen in "answer" gespeichert werden können.

Ein Formular für mehrere Events macht dann Sinn, wenn sich die Fragen eben nicht ändern. Bei dem Zeltlager hier ist es zum Beispiel so, dass zwei A5-Seiten mit Fragen ausgefüllt werden müssen. Da hat niemand Bock zwei Mal das gleiche Formular zu erstellen! Außerdem kann man immer wieder für verschiedene kleine Veranstaltungen ein kleines Formular verwenden, ohne jedes Mal ein neues zu erstellen. In dem Punkt ist meine Meinung, dass sich die Applikation nach dem Anwendungsfall richten sollte und nicht umgekehrt! Ändert sich nun das Formular, dann kann man immernoch ein neues erstellen. Zum besseren Verständnis hänge ich mal zwei zensierte Screens an.
Anhang anzeigen 328375Anhang anzeigen 328376

Bsp:
Jahr 2012: Event "Kinderfreizeit X" wird angelegt mit passendem Formular. 50 Leute tragen ihre Daten ein.
Jahr 2013: Event "Kinderfreizeit X" finder wieder statt, also nimmt man dasselbe Formular (= selbe ID). Dann stellt man fest, dass eine alte Angabe unnötig ist und dafür eine neue hinzukommt.
Ergebnis: Die Daten, die 2012 eingegeben wurden, passen nicht mehr wirklich zum Formular.

Mein Vorschlag:
Pro Event ein neues Formular (d.h. die form-Tabelle würde rausfliegen, weil man dann auch direkt die questions mit dem event verbinden könnte). Da kannst du ja 'ne simple Option einbauen, um das Formular von vor x Jahren zu kopieren, damit man es anpassen kann.

Ist eine Freizeit zu Ende, so werden die Antworten aus der Datenbank gelöscht! Rechtlich darf man die ja vermutlich auch nicht länger als notwendig speichern. Rechtliche Fragen sind aber gerade noch in der Klärung, aber ich vermute, dass es auf direktes Löschen hinausläuft. "Pro Event ein neues Formular" fällt aus den obenstehenden Gründen (Bequemlichkeit für die Veranstalter) aus.

2.:
- Ein Formular kann beliebig viele Fragen haben Check!
- Eine Antwort ist definiert durch: Frage, Formular, Event Check!
Das Formular ist hier unnötig, da das angegebene Event nur genau ein Formular haben kann Check!

EDIT2: Denke daran für die Fragen eine zusätzliches Spalte einzuführen, damit die Fragen auch genau in der Reihenfolge ausgegeben werden, wie du sie willst.

Momentan steht das nicht auf dem Plan, zumindest in den 150 Stunden, aber wenn das Ding durch ist, dann kommt das Feintuning!

Aktualisiertes Schaubild:

 

[benneq]

Das Diagramm schrumpft von mal zu mal Sehr schön.


... Das mit den Rechten für Event/Formular habe ich immer noch nicht kapiert. In welcher Reihenfolge läuft das ganze ab und wer darf was?

Bsp.1:
User A erstellt Event E
User A erstellt Form F
User A weist dem Event E das Form F zu

Oder Bsp.2:
User A erstellt Event E und muss direkt ein Form auswählen, weil man sonst kein Event erstellen kann

Weiteres:
Muss dem Eventersteller auch das Formular gehören? Oder kann der Eventersteller ein völlig beliebiges Formular benutzen? Aber dann hätte er ja keine Kontroller mehr über den Inhalt des Fomulars, weil er es nicht bearbeiten kann bzw. die Bearbeitung von anderen nicht unterbinden kann.


P.S. Wieso kann das Event nun nur noch einer einzigen Person gehören und keiner Gruppe? ^^

 

[derBobby]

Ich finde es ja gerade zu köstlich, wie man aneinander vorbeireden kann!

Der korrekte Ablauf entsprechend deinem Beispiel 2:
- Veranstalter A erstellt ein Formular, falls keines oder kein passendes vorhanden ist
- Veranstalter A erstellt eine Veranstaltung und wählt in einem Dropdown das entsprechende Menü aus

Muss dem Eventersteller auch das Formular gehören? Oder kann der Eventersteller ein völlig beliebiges Formular benutzen? Aber dann hätte er ja keine Kontroller mehr über den Inhalt des Fomulars, weil er es nicht bearbeiten kann bzw. die Bearbeitung von anderen nicht unterbinden kann.

Momentan ist es so gedacht, dass jeder nur seine eigenen Formulare verwenden kann. Wie du richtig erkannt hast, hätte sonst ein Veranstalter keinerlei Kontrolle darüber, was mit dem Formular geschieht. Es ist von der Idee her aber auch nicht geplant, dass man Elemente nachträglich löschen kann. Bestenfalls die Beschreibung ändern oder neue hinzufügen.

Ich hoffe jetzt sind wir gedanklich synchron?!

PS: Wo steht denn, dass das Event einer Gruppe gehören soll?

 

[benneq]

Das war im vorletzten Diagramm noch der Fall Da gab's eine Many2Many Beziehung zwischen user und event.


Also wenn dem Veranstalter eines Events eh das Formular gehört, dann könntest du dir auch die accountid im Formular sparen

 

[derBobby]

Das ist wohl wahr!

 

[benneq]

So denn kannst du dich ja nun mit dem eigentlichen Part beschäftigen
(De)Serialisierung von Formular-Elementen.

Kannst ja mal von deinen Fortschritten berichten, oder nach Hilfe schreien