Um Facts später auch einfach hinzufügen zu können, habe ich die Datenbank jetzt grundlegend geändert. Neben der Tabelle für die Kunden "customers" und der Tabelle für die Ratings "ratings", gibt es jetzt eine Tabelle "facts" in der die Antworten stehen. D.h. Für jeden 'fact' zu einem 'rating' gibt es einen Eintrag mit den Daten zu welchem 'rating' der 'fact' gehört, zu welchem 'fact_type' und wie der Wert/die Antwort ist.
Datenbank
Und da habe ich auch schon das erste Problem... Ist der Wert des facts ('answer') immer eine Zahl, damit man damit rechnen kann? Ich habs jetzt erstmal als VARCHAR eingetragen, aber würde gerne hören, was ihr dazu sagt.
Um welchen 'fact' es sich handelt, wird wie gesagt mit der Referenz zur Tabelle "fact_types" gespeichert. Dort steht dann ein Name (zB "Berechnetes Eigenkapital") sowie die Fragestellung, die beim Eintragen von Fakten erscheinen soll. Außerdem habe ich ein Feld "question_type" vorgesehen, wo dann der Datentyp der Antwort festgelegt ist, falls also doch nicht jeder Wert als Zahl darstellbar ist.
Nun ist halt die Frage, was für Werte haben die Facts, kann man alle als Zahlen abbilden? Beim Eintragen des Facts reicht aber vermutlich nicht immer nur ein Textfeld, sondern es gibt ja auch Ja/Nein-Fragen, die dann über Radiobuttons eingegeben werden!? Gibt es vielleicht sogar Facts, wo man Auswahlmöglichkeiten hat? Wie würde man dies dann realisieren? Brauche ich noch weitere Tabellen für solche Typen um die Antwortmöglichkeiten einzutragen?
Nebenbei habe ich jetzt schonmal eine Kategorisierung vorgesehen, weil Phillip meinte es wäre gut, wenn man die Facts in Gruppen aufteilen kann. Also jeder 'fact_type' gehört zu einer Kategorie, die wiederum eine Unterkategorie von einer anderen Kategorie sein kann. Zur Zeit würde dort nur "hardfacts" und "softfacts" als Kategorien eingetragen sein. Aber das ganze kann man auch erstmal weglassen.
Btw: Kann man in der Tabelle "facts" nicht die id weglassen und als primary key das Tupel (rating_id, fact_type_id) nehmen? Vermutlich ist die Handhabung dann etwas schwieriger, oder? Bzw geht das bei mysql überhaupt? Nebensächlichkeit, aber würde mich mal interessieren.
Comments (3)
Hi,
ich kann dir nur was zum letzten Absatz sagen. Hatte bei mysql auch schon Tabellen die sich aus (x_id, y_id) zusammensetzten.
Ob das jetzt schwieriger ist oder nicht, kann ich leider nicht sagen.
Grüße
Tim
Posted by Tim | 14.11.07 16:04
Posted on 14.11.07 16:04
Hi Gerald,
aus MySQL-Sicht ist es natürlich kein Problem, zusammengesetzte Primärschlüssel zu verwenden. Du willst aber nicht in Rails damit arbeiten müssen... mach am besten einfach immer einen künstlichen INT-Primärschlüssel und lege nötigenfalls einen Constraint (auf Datenbank- und/oder Applikationsebene) an, der dafür sorgt dass gewisse Felder nur einmal in jeder Kombination vorkommen dürfen. In Rails kein Problem, in J** keine Ahnung ;-)
Zu der Sache mit den Antwort-Typen: ich hatte das damals bei einem ganz ähnlichen Problem so gemacht, dass der Antwort-Typ immer ein Varchar war und die Datentyp-Spalte angab, wie der darin gespeicherte string zu interpretieren war. Das konnte auch eine Liste sein, oder eben Ja/Nein-Antworten. Dazu hatte ich ein weiteres Feld, wo die möglichen Antworten (als irgendwie serialisiertes Array, z.B. YAML oder CSV) oder, im Falle von Freitextfeldern, einfach nichts standen. Hat prima funktioniert, ist aber vllt nicht so sauber wie wenn man die Antwortmöglichkeiten als separate Entität auslagert...
Grüße
Willem
Posted by Willem van Kerkhof | 29.11.07 14:24
Posted on 29.11.07 14:24
Danke für die Kommentare.
Jo, es geht. Man kann den Schlüssel aus zwei Spalten zusammensetzen und JavaEE hat damit (vermutlich) auch kein großes Problem - ich hab es nicht ausprobiert, aber zumindest gibt es eine Annotation, die vorsieht zwei Spalten zusammen als Primärschlüssel zu definieren. Mit Rails hab ich mich jetzt noch nicht befasst, aber ist auch egal, denn ich habe jetzt einfach die Lösung mit dem künstlichen Schlüssel genommen.
"dass der Antwort-Typ immer ein Varchar war und die Datentyp-Spalte angab, wie der darin gespeicherte string zu interpretieren war"
Genau so hab ich mir das auch gedacht. Das reicht vorerst auch so, nur frage ich mich, wie man die Antworten später geeignet automatisch auswerten kann. Aber der Reihe nach. Erstmal schreib ich die JavaEE Anwendung "fertig".
Posted by Gerald Schenke | 29.11.07 15:35
Posted on 29.11.07 15:35