Wiem, że zmagasz się z wieloma rzeczami naraz, ale najlepsza odpowiedź rozwiązuje problem iegami szybko minął w drodze do zrobienia tego w Perlu:
Ludzie często robią znacznie więcej, niż potrzebują na poziomie aplikacji, ponieważ nigdy nie nauczą się robić właściwych rzeczy w bazie danych (takich jak inne pytanie na co lepiej odpowiedzieć odpowiednim zapytaniem SQL zamiast Perl). Ale na marginesie, wiele osób robi to, ponieważ nie są w stanie zmienić schematu. Heurystyki społeczne, takie jak odpowiednia aplikacja piwa, czasami wygładzają tę ścieżkę. Trochę pracy, aby przekonać ludzi z bazy danych, później się opłaci. I, na marginesie, „pełen stos programistów” często pomija jakiekolwiek wyrafinowane użycie baz danych.
Nie będę zmuszać nikogo do czytania Database in Depth C.J. , ale prawidłowe ustawienie schematu ma dużą wartość. Prawidłowo mam na myśli, że wymaga najmniej wysiłku i złożoności jego użytkowania. Sprawy powinny być łatwe i nie powinieneś ich zmieniać na poziomie aplikacji.
Chcesz policzyć, ile razy wybrano każdą odpowiedź. Liczenie to coś, co bazy danych robią bardzo dobrze, więc niech zrobi to baza danych.
Masz kilka pytań. Pytania mają różne odpowiedzi. Ankiety grupują zestawy pytań. Ludzie odpowiadają na ankiety, łącząc swoje odpowiedzi z pytaniami.
Oto prosty projekt schematu (i w końcu pojawi się jakiś facet od baz danych i powie mi, że nie zrobiłem tego dobrze, ale to w porządku). Sztuczka polega na tym, że nic nie musi mieć wielu nieużywanych kolumn. Wszystko jest w zgrabnym małym pakiecie ("relacja" w "relacyjnej bazie danych"), który można łatwo połączyć z innymi rzeczami za pomocą "kluczy obcych" (np. question_id do mapowania odpowiedzi na pytanie). Odpowiedzi, na przykład, będą miały wiele wierszy dla tego samego question_id .
Jeśli ktoś chce wejść z fantazyjnymi narzędziami do modelowania i zrobić zdjęcie, to sięgnij. Oznaczę to jako wiki społeczności.
Table: Questions
id
text
Table: Answers
id
text
question_id
Table: Surveys
id
title
Table: SurveyQuestionSet
id
survey_id
question_id
Table: Respondent
id
text
Table: Response
id
respondent_id
survey_id
question_id
answer_id
Po prawidłowym odwzorowaniu i normalizacji (przeczytaj normalne formularze ), bardzo łatwo jest uzyskać żądane dane za pomocą SELECTów. Ideałem normalizacji jest po prostu nie powtarzanie informacji lub dopuszczenie ich do niespójnego stanu. W tych formach wiele rzeczy staje się znacznie prostszych do zrobienia.
A jeśli chcesz poćwiczyć takie rzeczy, Eksplorator danych Stackoverflow to zestaw rzeczywistych danych znormalizowany do tego, co tutaj przedstawiłem.
Teraz po prostu policz, ile razy answer_id pojawia się dla określonej kombinacji ankiety i pytania. Zręczne użycie GROUP BY wykonuje całą pracę za Ciebie. Nie musisz już przeszukiwać wierszy, patrząc na dziesiątki nieużywanych kolumn, próbując dowiedzieć się, jak je policzyć. Nie tylko to, ale możesz zrobić te rzeczy widoki
, co oznacza, że wpisujesz zapytanie raz, a baza danych udaje, że wyniki są tabelą. Następnie możesz po prostu zapytać o widok (więc wszystkie JOIN i podobnie są ukryte), co jest bardzo proste. Często pomijane są również procedury składowane.
