Jak to ugryźć - modelowanie danych

Problem dotyczy zaproszeń na spotkanie, które mogą być wysyłane do grup lub pojedynczych użytkowników.

Wymagane jest przedstawienie informacji:

1. ile osób jeszcze nie odpowiedziało na zaproszenie
2. kto, kogo, kiedy zaprosił
3. historia odpowiedzi (jeśli ktoś zmieni zdanie, etc powinno być widoczne)

Poki co obrałam taka taktykę:
Mam tabele CALENDAR_INVITATIONS (tu trzymam dane o wysłanych zaproszeniach), CALENDAR_RESPONSES (tu trzymam dane z odpowiedzią użytkownika - czy weźmie udział, wiadomość, etc).
Teraz, jeśli na spotkanie jest zaproszona Grupa A i ktoś w miedzy czasie do tej grupy dojdzie lub ja opuści, odpowiednio albo ma dostać zaproszenie, albo zostać wykreślony z listy uczestników.

I tu moje pytania:

• czy lepiej przy zaproszeniu grupy pobrać wszystkich jej członków i wstawić rekordy do CALENDAR_RESPONSES z zaznaczeniem, ze oczekuje na odpowiedz?
• czy lepiej CALENDAR_RESPONSES trzymać tylko te odpowiedzi, które były wysłane przez użytkowników, a przy każdym otwarciu spotkania sprawdzać ile osób jest w zaproszonych grupach i kto jeszcze nie odpowiedział?
• jak w ogole połączyć CALENDAR_RESPONSES z CALENDAR_INVITATIONS? (dodam, ze jedna osoba może być zaproszona kilka razy, jako członek kilku zaproszonych grup)

Dzięki za wszelkie pomysly

ja bym przy wysyłaniu zaproszeń nie brał grupy jako całości pod uwagę a traktował każde zaproszenie jako osobiste - wtedy wszelkie problemy związane z reorganizacją grupy znikną

Przestań myśleć tabelami i bazą danych, zacznij myśleć obiektami. Potem tylko zapisuj do bazy.
Pomyśl jakich obiektów potrzebujesz i jaką mają realizować funkcjonalność - jakie mają mieć zachowanie.

Skoro masz grupy i osoby może powinny przechowywać zaproszenia? Grupy ogólnie listę (ala template, nie imienny), a osoby już szczegółowo zaproszenie konkretne dla nich ze statusem odrzucone/przyjęte/"decyzja nie zapadła" i w trakcie mogłyby zmieniać zdanie.
Pytanie co z zaproszeniami użytkownika który odłącza się od grupy, usuwać czy zostawiać dla statystyk. Jak zostawiać co jeśli dołączy znów do grupy.

W momencie odłączenia od grupy zaproszenie byłoby usuwane z takiej osoby. Samo zaproszenie też mogłoby przechowywać informacje kto jest zaproszony i kto potwierdził.
Analogicznie jak ktoś dołącza do grupy, dostaje wszystkie zaproszenia z "templatów" które ta grupa aktualnie przechowuje.
I Tutaj dodatkowe pytanie co jeśli to samo zaproszenie użytkownik ma z kilku grup, co wtedy robić? Raczej zostawić dopóki ma z którejkolwiek grupy. Lub można by je było wtedy traktować jako dwa oddzielne. To też musisz przemyśleć wcześniej.

Template też mógłby być miejscem zbierającym i posiadającym informacje o zaproszeniach z niego utworzonych dla użytkowników. Wtedy oczywiście nazwa powinna być lepsza.

AreQrm napisał(a):

Przestań myśleć tabelami i bazą danych, zacznij myśleć obiektami. Potem tylko zapisuj do bazy.
Pomyśl jakich obiektów potrzebujesz i jaką mają realizować funkcjonalność - jakie mają mieć zachowanie.

W taki właśnie sposób podchodzę do problemu. Zwróć proszę uwagę, ze najpierw przedstawiłam istotę problemu.

AreQrm napisał(a):

Skoro masz grupy i osoby może powinny przechowywać zaproszenia? Grupy ogólnie listę (ala template, nie imienny), a osoby już szczegółowo zaproszenie konkretne dla nich ze statusem odrzucone/przyjęte/"decyzja nie zapadła" i w trakcie mogłyby zmieniać zdanie.

Tak, własnie w taki sposób próbuje to rozgryźć. Moje Invitations - to wysłane zaproszenia (do kogo, kiedy, przez kogo). Responses to odpowiedzi poszczególnych uczestników spotkania.

AreQrm napisał(a):

Pytanie co z zaproszeniami użytkownika który odłącza się od grupy, usuwać czy zostawiać dla statystyk. Jak zostawiać co jeśli dołączy znów do grupy.

Musze miec możliwość przedstawienia historii danego zaproszenia, czyli ze ktoś został zaproszony przez dana osobę, później odpowiedział ze przyjdzie, później jednak grupa poprzez która był zaproszony została usunięta z listy uczestników, etc. To myślę, ze obsłużę poprzez dodanie czegoś w stylu response_seq i participation_type, które będzie słownikiem przechowującym "sposób uczestnictwa w spotkaniu" (w tym wykreślony z listy, czeka na odpowiedz, etc)

AreQrm napisał(a):

W momencie odłączenia od grupy zaproszenie byłoby usuwane z takiej osoby. Samo zaproszenie też mogłoby przechowywać informacje kto jest zaproszony i kto potwierdził.
Analogicznie jak ktoś dołącza do grupy, dostaje wszystkie zaproszenia z "templatów" które ta grupa aktualnie przechowuje.

@AreQrm rozwiń to proszę, nie jestem pewna cz rozumiem.

AreQrm napisał(a):

I Tutaj dodatkowe pytanie co jeśli to samo zaproszenie użytkownik ma z kilku grup, co wtedy robić? Raczej zostawić dopóki ma z którejkolwiek grupy. Lub można by je było wtedy traktować jako dwa oddzielne. To też musisz przemyśleć wcześniej.

Beda traktowane jako dwa oddzielne

AreQrm napisał(a):

Template też mógłby być miejscem zbierającym i posiadającym informacje o zaproszeniach z niego utworzonych dla użytkowników. Wtedy oczywiście nazwa powinna być lepsza.
Czy mógłbyś to bardziej szczegółowo rozpisać?