Jakie tabele i relacje bazy danych mysql wspierałyby ankietę Q & A z pytaniami warunkowymi? [zamknięte]
Pracuję teraz nad dość prostym systemem badań. Schemat bazy danych będzie prosty: tabela Survey, w relacji jeden do wielu z Tabelą Question, która jest w relacji jeden do wielu z tabelą Answer i tabelą PossibleAnswers.
Ostatnio klient zdał sobie sprawę, że chce mieć możliwość pokazywania pewnych pytań tylko osobom, które udzieliły jednej konkretnej odpowiedzi na jakieś poprzednie pytanie (np. Kupujesz papierosy? po nim będzie What ' s your ulubiona marka papierosów?, nie ma sensu zadawać drugiego pytania niepalącemu).
Teraz zacząłem się zastanawiać, jaki byłby najlepszy sposób na zaimplementowanie tego warunkowych pytań w kontekście mojego schematu bazy danych? Jeśli question A mA 2 możliwe odpowiedzi: A i B, a question Bpowinien pojawić się tylko użytkownik Jeśli odpowiedź brzmiała A?
Edit: szukam sposobu na przechowywanie informacji o wymaganiach w bazie danych. Postępowanie z danymi będzie prawdopodobnie zrobione po stronie aplikacji, ponieważ moje umiejętności SQL są do bani;)
4 answers
Projektowanie Bazy Danych Ankiety
Ostatnia Aktualizacja: 5/3/2015
Pliki diagramu i SQL są teraz dostępne pod adresem https://github.com/durrantm/survey
Jeśli używasz tej (górnej) odpowiedzi lub dowolnego elementu, Dodaj opinię na temat ulepszeń !!!
To prawdziwy klasyk, robiony przez tysiące. Zawsze wydają się "dość proste" na początek, ale aby być dobrym, jest to w rzeczywistości dość złożone. Aby to zrobić w Rails użyłbym modelu pokazanego w załączony schemat. Jestem pewien, że dla niektórych wydaje się to zbyt skomplikowane, ale po zbudowaniu kilku z nich, na przestrzeni lat, zdajesz sobie sprawę, że większość decyzji projektowych są bardzo klasyczne wzorce, najlepiej rozwiązać za pomocą dynamicznej elastycznej struktury danych na początku.Więcej szczegółów poniżej:
Szczegóły tabeli dla tabel kluczowych
Odpowiedzi
Tabela Odpowiedzi jest krytyczna, ponieważ rejestruje rzeczywiste odpowiedzi użytkowników. Zauważysz, że odpowiedzi na linki do question_options , a nie questions. To jest celowe.
Input_types
Input_types to typy pytań. Każde pytanie może być tylko jednego typu, np. wszystkie tarcze radiowe, wszystkie pola tekstowe itp. Użyj dodatkowych pytań, gdy jest (powiedzmy) 5 radio-tarcze i 1 pole wyboru " Dołącz?"opcja lub jakaś taka kombinacja. Oznacz dwa pytania w widoku użytkowników jako jedno, ale wewnętrznie mają dwa pytania, jedno dla radiotelefonów, jedno dla pola wyboru. W tym przypadku pole wyboru będzie miało grupę 1.
Option_groups
Option_groups i option_choices pozwalają budować 'wspólne' grupy. Na przykład we wniosku o nieruchomość może pojawić się pytanie " ile lat ma nieruchomość?'. Odpowiedzi mogą być pożądane w zakresach: 1-5 6-10 10-25 25-100 100+
Następnie, na przykład, jeśli istnieje pytanie o wiek przyległej nieruchomości, a następnie badanie będzie chciał "ponownie wykorzystać" powyższe zakresy, tak aby te same option_group i options zostały użyte.
Units_of_measure
Units_of_measure jest jak brzmi. Niezależnie od tego, czy są to cale, kubki, piksele, klocki czy cokolwiek innego, możesz je zdefiniować raz tutaj.
FYI: chociaż ogólny charakter, można utworzyć aplikację na szczycie tego schematu, a ten schemat jest dobrze dostosowany do frameworka Ruby On Rails z konwencjami takimi jak "id" dla klucza podstawowego dla każdej tabeli. Również relacje są proste one_to_many ' s nie ma wiele_to_many lub has_many throughs potrzebne. Prawdopodobnie dodałbym has_many: throughs i / lub :delegatów, aby uzyskać takie rzeczy, jak survey_name z indywidualnej odpowiedzi łatwo bez.wiele.chaining.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-13 10:51:17
Możesz również pomyśleć o złożonych regułach i mieć pole warunkowe oparte na łańcuchu znaków w tabeli pytań, akceptując / analizując dowolne z nich:
- A (1)=3
- ((A (1)=3) i (A(2)=4) )
- A(3)>2
- (A(3)=1) i (A(17)!=2) I C (1)
Gdzie A (x) = y oznacza "odpowiedź pytania X jest y", A C (x) oznacza warunek pytania x (domyślnie jest true)...
Pytania mają pole zamówienia, a ty przechodzisz przez nie jeden po drugim, pomijając pytania, gdzie warunek jest fałszywy.
Powinno to umożliwić badania o dowolnej złożoności, Twój GUI może automatycznie tworzyć je w "trybie prostym" i pozwolić na i "tryb zaawansowany", w którym użytkownik może wprowadzić równania bezpośrednio.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-14 00:35:36
Jednym ze sposobów jest dodanie tabeli "wymagania dotyczące pytań" z polami:
- question_id (link do " która marka?"pytanie)
- required_question_id (link do " Czy palisz?"pytanie)
- required_answer_id (link do odpowiedzi "tak")
W aplikacji sprawdzasz tę tabelę, zanim zadasz określone pytanie. Dzięki oddzielnej tabeli łatwo jest dodać wymagane odpowiedzi (dodanie kolejnego wiersza dla odpowiedzi "czasami" itp...)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-12 11:29:13
Osobiście w tym przypadku użyłbym opisanej przez Ciebie struktury i wykorzystałbym bazę danych jako głupi mechanizm przechowywania. Jestem fanem wprowadzania tych złożonych i zależnych ograniczeń w warstwie aplikacji.
Myślę, że jedynym sposobem, aby wyegzekwować te ograniczenia bez budowania nowych tabel dla każdego pytania z obcymi kluczami dla innych, jest użycie rzeczy T-SQL lub innych mechanizmów specyficznych dla dostawcy do budowania wyzwalaczy baz danych w celu wyegzekwowania tych ograniczeń.
W aplikacji poziom masz o wiele więcej możliwości i łatwiej jest portować, więc wolałbym tę opcję.
Mam nadzieję, że pomoże Ci to w znalezieniu strategii dla Twojej aplikacji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-12 11:36:12