Projekt bazy danych dla ankiety [zamknięty]

Mój projekt jest pokazany poniżej.

Ostatni skrypt create znajduje się w https://gist.github.com/durrantm/1e618164fd4acf91e372

Skrypt i Stół roboczy mysql.plik mwb dostępny jest również w
https://github.com/durrantm/survey

Zdecydowanie opcja # 2, również myślę, że możesz mieć niedopatrzenie w obecnym schemacie, możesz chcieć innej tabeli:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

Każde pytanie będzie prawdopodobnie miało określoną liczbę odpowiedzi, z których użytkownik może wybrać, a następnie rzeczywiste odpowiedzi będą śledzone w innej tabeli.

Bazy danych są zaprojektowane do przechowywania wielu danych, a większość z nich jest bardzo dobrze skalowana. Nie ma potrzeby używania mniejszej normalnej formy po prostu, aby zaoszczędzić miejsce.

Ogólnie rzecz biorąc, modyfikowanie schematu w oparciu o coś, co użytkownik może zmienić (np. dodanie pytania do ankiety) powinno być uważane za dość śmierdzące. Są przypadki, w których może to być właściwe, szczególnie w przypadku dużych ilości danych, ale zanim zaczniesz się zanurzać, dowiedz się, w co się pakujesz. Posiadanie tylko tabeli "odpowiedzi" dla każdej ankiety oznacza, że dodawanie lub usuwanie pytań jest potencjalnie bardzo kosztowne i bardzo trudno jest przeprowadzić analizę w pytaniu-agnostic sposób.

Myślę, że twoje drugie podejście jest najlepsze, ale jeśli jesteś pewien, że będziesz miał wiele problemów ze skalą, jedna rzecz, która działała dla mnie w przeszłości, to podejście hybrydowe: {]}

1. Utwórz szczegółowe tabele odpowiedzi, aby przechowywać odpowiedzi na pytania, jak opisano w 2. Dane te zazwyczaj nie będą bezpośrednio pobierane z aplikacji, ale będą wykorzystywane do generowania danych podsumowujących dla tabel raportowania. Prawdopodobnie chciałbyś również zaimplementować jakąś formę archiwizacji lub skasowanie tych danych.
2. w razie potrzeby utwórz również tabelę odpowiedzi z 1. Może być używany, gdy użytkownicy chcą zobaczyć prostą tabelę wyników.
3. W przypadku wszelkich analiz, które należy wykonać w celach raportowania, zaplanuj zadania, aby utworzyć dodatkowe dane podsumowujące na podstawie danych z 1.

Jest to absolutnie dużo więcej pracy do wdrożenia, więc naprawdę nie radziłbym tego, chyba że wiesz na pewno, że ta tabela będzie działać na ogromną skalę obawy.

Drugie podejście jest najlepsze.

Jeśli chcesz go jeszcze bardziej znormalizować, możesz utworzyć tabelę dla typów pytań

Proste rzeczy do zrobienia to:

• Umieść bazę danych i zaloguj się na własnym dysku, nie wszystkie NA C jako domyślne
• Utwórz bazę danych tak dużą, Jak to konieczne, aby nie mieć przerw w czasie, gdy baza danych rośnie

Mieliśmy tabele logów w tabeli SQL Server z 10 milionami wierszy.

Nr 2 wygląda dobrze.

Dla tabeli z zaledwie 4 kolumnami nie powinno być to problemem, nawet z dobrymi kilkoma milionami wierszy. Oczywiście może to zależeć od tego, jakiej bazy danych używasz. Jeśli to coś takiego jak SQL Server to nie byłoby problemu.

Prawdopodobnie chciałbyś utworzyć indeks w polu QuestionID, w tabeli tblanswer.

Oczywiście musisz określić, jakiej bazy danych używasz, a także szacowane wolumeny.

Wygląda na całkiem kompletną ankietę smiple. Nie zapomnij dodać tabeli "otwartych wartości", w której klient może wyrazić swoją opinię za pomocą pola tekstowego. Połącz tę tabelę za pomocą klucza obcego z odpowiedzią i umieść indeksy we wszystkich kolumnach relacyjnych, aby uzyskać wydajność.

Liczba 2 jest poprawna. Używaj poprawnego projektu do momentu wykrycia problemu z wydajnością. Większość RDBMS nie będzie miała problemu z wąską, ale bardzo długą tabelą.

Posiadanie dużej tabeli odpowiedzi, samo w sobie, nie jest problemem. Dopóki indeksy i ograniczenia są dobrze zdefiniowane, powinno być dobrze. Twój drugi schemat wygląda dobrze.

Biorąc pod uwagę odpowiedni indeks twoje drugie rozwiązanie jest znormalizowane i dobre dla tradycyjnego systemu relacyjnych baz danych.

Nie wiem jak wielki jest ogromny, ale powinien pomieścić bez problemu kilka milionów odpowiedzi.

Możesz zapisać cały formularz jako łańcuch JSON.

Nie jestem pewien twoich wymagań, ale takie podejście zadziała w pewnych okolicznościach.