Welches Datenbankschema zum Speichern von Umfrageantworten verwendet werden soll

Question

Ich bin für die Entwicklung eines Vermessungssystems für unseren Kunden erforderlich. Es basiert auf asp.net, und die verwendete Datenbank ist oracle.

Ich habe keine Erfahrung hier so ich um Rat fragen möchte:

1. Welches Datenbankschema für die Speicherung von Benutzerantworten verwenden, fürchte ich mein aktuelles Design ist wahrscheinlich Performance-Problem haben ...

Über die Umfrage:

1. Es werden zwei oder mehr Erhebungen zur gleichen Zeit los sein.
2. Umfragen können einmal pro Jahr oder häufiger ausgelöst werden, daher denke ich, dass ich eine Übersichtstabelle benötige.
3. Umfragen zielen verschiedene Produkte, so dass es werde

Derzeit mein Design eine Zuordnung zwischen Produkten und Erhebungen sein:

Umfrage Kategorie Tabelle

+------------+--------------+ 
| CatageryId | CatageryName | 
+------------+--------------+ 
|   1 | cat1   | 
|   2 | cat2   | 
+------------+--------------+ 

Umfrage Kategorie Versionstabelle

+-----------+------------+--------------------+ 
| VersionId | CatageryId | VersionDescription | 
+-----------+------------+--------------------+ 
|   1 |   1 | 'cat1 version1' | 
|   2 |   1 | 'cat1 version2' | 
|   3 |   2 | 'cat2 version1' | 
+-----------+------------+--------------------+ 

Umfragezeitraum Tab le

+----------+--------------------+ 
| PeriodId | PeriodDescription | 
+----------+--------------------+ 
|  1 | 'cat1 period2016' | 
|  2 | 'cat1 period2017' | 
|  3 | 'cat2 period2016' | 
+----------+--------------------+ 

Befragungszeit-Version Kartentabelle

+----------+-----------+ 
| PeriodId | VersionId | 
+----------+-----------+ 
|  1 |   1 | 
|  1 |   2 | 
|  2 |   1 | 
|  3 |   3 | 
+----------+-----------+ 

Eine Version-Frage Kartentabelle

+--------------+------------+ 
| VersionId | | QuestionId | 
+--------------+------------+ 
|   1 |   1 | 
|   1 |   2 | 
|   1 |   3 | 
|   2 |   1 | 
|   2 |   2 | 
|   3 |   1 | 
+--------------+------------+ 

Eine Version-Produktkartentabelle

+-----------+-----------+ 
| VersionId | ProductId | 
+-----------+-----------+ 
|   1 | 'prodA' | 
|   1 | 'prodB' | 
|   1 | 'prodC' | 
|   2 | 'prodA' | 
+-----------+-----------+ 

Und to Store Die Umfrageergebnisse müssen ich angeben viele duplizierte Informationen zwischen den Reihen des Rekords:

Benutzer Antwort Tabelle +----------+------------+----------+-----------+-----------+--------+-----------+ | AnswerId | QuestionId | PeriodId | UserId/Ip | ProductId | Answer | VersionId | +----------+------------+----------+-----------+-----------+--------+-----------+ | 1 | 1 | 1 | 'adam' | 'prodA' | 'Yes' | 2 | | 2 | 2 | 1 | 'Joe' | 'prodA' | 'Yes' | 2 | | 3 | 1 | 2 | 'adam' | 'prodB' | 'A' | 3 | +----------+------------+----------+-----------+-----------+--------+-----------+ Wir zig Produkte und Tausenden von Benutzern für dieses System zu erwarten. Nehmen wir an, 30 Produkte, 5000 Benutzer, 50 Fragen pro Umfrage und 4 Umfragen pro Jahr

im aktuellen Design, wird es 5000 * 4 * 50 * 30 = 30 Millionen Datensätze in der Benutzerantwort Tabelle per hinzugefügt werden Jahr, Ich habe wirklich Angst, wenn es noch richtig funktionieren könnte ..., also irgendwelche Vorschläge zur Optimierung?

Bearbeiten 1: Fügen Sie die Spalte VersionId wie vorgeschlagen in die Benutzerantworttabelle ein.

Answer 1

Dies sieht aus wie ein Fall von vorzeitigen Optimierung. Sie sollten sich wahrscheinlich mehr Gedanken über Korrektheit und Flexibilität als über die Leistung machen.

30 Millionen Zeilen pro Jahr, besonders in diesen mageren Tabellen, sind eine kleine Datenmenge für jedes Oracle-System. Machen Sie sich noch keine Gedanken über Indizes und Partitionierung, diese können später bei Bedarf hinzugefügt werden.

Ihre Lösung ähnelt dem Entity Attribute Value (EAV) -Modell. Es ist wert, diesen Begriff zu kennen, da viel darüber geschrieben wurde. Es gibt zwei häufige Probleme mit EAV Modelle, die Sie vermeiden wollen:

1. Extreme vermeiden. Verwenden Sie nicht EAV für alles, aber vermeiden Sie es auch nicht vollständig. EAV ist langsam und unbequem im Vergleich zu einer normalen Tabellenstruktur. Es sollte nicht für alle interessanten Spalten verwendet werden, sonst haben Sie eine Datenbank innerhalb einer Datenbank erstellt. Wenn beispielsweise in praktisch jeder Umfrage Felder wie ein Benutzername und ein Datum erstellt wurden, speichern Sie diese als normale Spalten und nicht in einer generischen Spalte. Es ist in Ordnung, eine Spalte zu haben, die nur zu 99% ausgefüllt ist. Auf der anderen Seite ist es eine schlechte Idee, immer die EAV zu vermeiden und zu versuchen, etwas zusammen mit 1.000 Spaltentabellen oder objektrelationalen Typen zu hacken.

2. Verwenden Sie immer den richtigen Typ. Immer, immer, immer Daten als den richtigen Typ speichern. Speichern Sie Zahlen als Zahlen, Datumsangaben als Datumsangaben und Zeichenfolgen als Zeichenfolgen. Ihre Abfragen werden einfacher, schneller und sicherer, wenn Sie mindestens drei Spalten für die Daten haben: ANSWER_NUMBER, ANSWER_STRING, ANSWER_DATE. Ich erkläre das Typ Sicherheitsproblem mehr in this answer. Diese zusätzlichen Spalten sehen im Modelldiagramm möglicherweise schlecht aus, aber sie sind lebensrettend, wenn Sie die Daten abfragen.