![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 249 Pomógł: 30 Dołączył: 18.07.2007 Ostrzeżenie: (0%) ![]() ![]() |
Witam
Mam za zadanie stworzyć system w którym wg wstępnych założeń ma być około 100 pól w bazie danych, klient chciałby mieć możliwość jeśli to możliwe ingerencji w zestaw pytań dla interfejsu w którym użytkownik odpowiadając na pytania będzie udzielał informacji o swojej organizacji. tabela pytanie: id_pytanie INT PK pytanie nazwa_pola tabela walidacja: id_walidacja PK opcje tabela pytanie_walidacja: id_pytanie PK id_walidacja FK wartosc (ewentualna wartość - np minimum 10 znaków) tabela odpowiedzi: id_odpowiedz PK id_pytanie FK odpowiedz_tresc odpowiedz_wartosc tabela odpowiedzi_wartosci: id_organizacja PK id_odpowiedz PK wartosc Ponieważ nie mam doświadczenia z takimi strukturami pytam o sugestie dotyczące w/w schematu oraz ewentualne wskazówki. Czy implementacja tego rozwiązania nie przysporzy kłopotów przy póżniejszym użytkowaniu (dodawaniu, usuwaniu, wyszukiwaniu, edycji rekordów - już nie pytań). Rekordów w głównej tabeli nie powinno być dużo - od 400 do 1000, ale przy pełnym wypełnieniu odpowiedzi w tabeli z wartościami odpowiedzi będzie niewspółmiernie więcej rekordów. |
|
|
![]()
Post
#2
|
|
Newsman Grupa: Moderatorzy Postów: 2 033 Pomógł: 290 Dołączył: 21.12.2007 Skąd: Łódź ![]() |
Chyba da sie to trochę uprościć.
Najpierw trzeba sobie zadać pytanie - co tak naprawdę bedzie w bazie przechowywane i jak będzie ze soba powiązane i pod tym kątem tworzyć strukturę bazy. Patrząc na powyższe, mamy do czynienia z serwisem, gdzie ORGANIZACJE będą odpowiadac na PYTANIA, udzielając prawidłwoych ODPOWIEDZI (nie wiem, do czego ta walidacja, bo nie wyjaśniasz za bardzo). Biorąc to pod uwagę, powinniśmy mieć następujące tabele: ORGANIZACJE - dane na temat organizacji udzielających odpowiedzi PYTANIA - pytania, na które trzeba udzielic odpowiedzi ODPOWIEDZI - tabela zawierająca odpowiedzi organizacji na pytania. Pomiędzy tymi tabelami będą zachodzic relacje: jeden do wielu (pomiędzy ORGANIZACJA a ODPOWIEDZI - ponieważ będzie wiele odpowiedzi jednej organizacji) oraz jeden do wielu pomiędzy PYTANIE i ODPOWIEDZI, ponieważ na jedno pytanie będzie wiele odpowiedzi (każda organizacja odpowiada na te same pytania rozumiem). Moja propozycja wygląda następująco: ORGANIZACJA o_id INT PK AI o_name o_address ... itd. (dane organizacji PYTANIA p_id INT PK AI p_tresc ODPOWIEDZI odp_id INT PK AI odp_tresc <- tresc odpowiedzi na dane pytanie o_id <- ID organizacji p_id <- ID pytania - te trzy pola tworzą Ci komplet do pobrania odpowiedzi na dane pytanie udzielone przez dana organizację I to wszystko. Chcąc pobrać wszystkie odpowiedzi i pytania danej organizacji robisz: SELECT * FROM ODPOWIEDZI ODP , PYTANIA P INNER JOIN PYTANIA P ON ODP.p_id = P.p_id WHERE ODP.org_id = 'id_wybranej_organizacji'; To moja propozycja. Szczegóły będą zależeć od wymagań Twojej aplikacji. Ale w takim przypadku max. 3 tabele wystarczą do obsłużenia takiej funkcjonalności. |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 249 Pomógł: 30 Dołączył: 18.07.2007 Ostrzeżenie: (0%) ![]() ![]() |
Dzięki za odpowiedź.
Jeśli chodzi o tabelę organizacji nie dawałem jej - bo nie ona jest tu sednem sprawy. Walidacja jest potrzebna ponieważ niektóre pola są wymagane, przy pytaniach otwartych ograniczamy liczbę znaków, bądź chcemy by odpowiedź była datą, liczbą... Dwie tabele do walidacji ponieważ nie chcę przechowywać tych samych flag do walidacji przy każdym pytaniu. Zaplanowałem tyle tabel ponieważ większość odpowiedzi mam zdefiniowanych z góry, część jest typu: Inna (podaj jaka) i dla tych wariantów głównie potrzebuję walidacji. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 20.09.2025 - 08:03 |