how should we design the DB?

[wdiechmann]

I'm taking a stab at it - and this is the first draft

DB design

This is where we're sketching out the information which Ticket will persist for us.

As a user [contact with credentials] I would like to see what tickets [events] my coworkers [contacts belonging to contact] and I have.

As a participating scout [contact with credentials] I'd like to be able to comment [post belonging to a post] on a comment [post] where someone [contact] suggests that I [contact belonging to event] should accept responsibility [with role "delegated_to"] for a ticket labeled 'Åbningslejrbål' [event]

Core Elements

• event
• contact
• post

We could totally abstract this away by adding

• event

  • id
  • resource_id
  • ...

• contact

  • id
  • resource_id
  • ...

• post

  • id
  • resource_id
  • ...

• resource

  • id
  • ancestors

• resource_events

  • resource_id
  • event_id

• resource_contacts

  • resource_id
  • contact_id

• resource_posts

  • resource_id
  • post_id

[JacobArrow]

:D

[wdiechmann]

Ja - vi kan faktisk (næsten) modellere hele lejren med de 3 “core elementer” - er det ikke lidt vildt!

Den 17. nov. 2020 kl. 17.04 skrev JacobArrow notifications@github.com:

:D

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SL2022/ticket/issues/9#issuecomment-729028467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABPFXJGCLEILHWCPCNC53DSQKNKJANCNFSM4TYVIWDQ.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/SL2022/ticket/issues/9#issuecomment-729028467", "url": "https://github.com/SL2022/ticket/issues/9#issuecomment-729028467", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]