schema design union vs flat properties

Question

when I have a parent Object type that needs to point to a child Object type but that child Object's type can be of several types and only one can be chosen and populated. I see 2 options I can do with regard to graphql schema design.

option 1 - use union

type child1{......}
type child2{......}
union chooseOne = child1 | child2
type parent{
         ref: chooseOne
}

option 2 use multiple props and have only one with data - the rest with nulls

type child1{......}
type child2{......}
type parent{
     ref1: child1
     ref2: child2
}

is there a 3rd option I am not thinking of? I am not that please with either. I feel like I am missing something... can anyone please comment? thanks! (edited)

Answer 1

am I missing a third possible option?

using an array

type Meeting{
  .........(some properties)
  recurrences : [Recurrence]
}

union Recurrence = Once | WeeklyRecurrence | MonthlyRecurrence | DailyRecurrence

Of course it looks like a relation ... and it is ... and gives you more possibilities.

• all of them can have validFrom and validUntil times - you can filter out all historical entries automatically without manual disabling/removing
• you can have AND combinations instead OR, for example 'every working day at 10.00, additionally at 15.00 on fridays'
• you can process recurrence entries separately f.e. for notifications (having meeting id just fetch attendees from another relation)

But in fact maybe you don't need separate recurrence types at all, only one field/property (enumerated types) to know which fields are required for render/forms/resolver/mutations etc.
... all of them can use the same DB table, the same record structures in both cases (types mapped to enumed type field).

Update

I prefer 2nd option:

• it's more readable/debuggable
• it's easier to handle - if(ref1)...<Ref1Component data={ref1}/> ... passing union data object you don't have info about type!
• unions sometimes leads to troubles like this