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 ***@***.***>: :D — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABPFXJGCLEILHWCPCNC53DSQKNKJANCNFSM4TYVIWDQ>. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#9 (comment)", "url": "#9 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]