Народ. А можно мыслишки на тему послушать ? Есть сущность -

Напоминание
Оно может быть для зарегистрированного пользователя (юзер ИД)
или для просто по мылу для кого угодно (это в плане куда шлем напоминание)

так же оно может быть для разных обьектов - событие(по сути некая конкретная дата), повторяющиеся событие(раз в день) и конкретное событие из повторяющегося события

вот я думаю как лучше организовать структуру сущностей
какие есть мысли
1. одна на все целиком - мысль не очень нравится
2. наследование - тоже плоховато потому как дети и будут напоминалками как и родитель, но у всех детей будут свои методы
3. сделать интерфейс и его реализовать - аналогично как у п.2 - вряд ли это можно обьеденить
4. делать на каждый вариант свою сущность ? (RegisteredUserEventReminder, RegisteredUserRecurringEventReminder...) - такое себе удовольствие...

кто что скажет ?

У нас такое сделано на коллбэках. Сущность одна, бд одна, дальше логика рулится коллбэком для конкретного уведомления.

т.е у вас по сути ReminderEntity setUserId setEmail setTarget(event|recurringEvent|specificDateAtRecurringEvent) ?

практически да, дату создания, дату обновления, дату протухания и дату уведомления храним как отдельные свойства, не привязанные к коллбэку.

Ответ зависит от разницы между разными сущностями и "для email или для зарегистрированного". Возможно общую часть логики можно отделить от ресипиента. Если логика одинаковая то первый вариант. Если нет - надо разбираться где отличия Словом мало инфы

разница в привязке к пользователю по ид если для зареганного то потом возьмем его мыло по ид пользователя если для незареганного, то сразу впишем мыло и вписывать сразу мыло зареганного нельзя, его можно сменить у зареганного пользователя, а я не хочу еще и синхронизировать мыло у пользователя и в напоминалке

1 можно менять мыло в уведомлениях после того как пользователь сменил свое и того разницы не будет 2 Или не вижу смысла в чем разница между зареганым и не зареганым пользоватлем там и там можно создать пользоватля и его мыло. То что пользователь зареган к айди пользовтеля и его емейла имеет совершенно опосредованое отношение. В таком разе тоже разницы нет и можно связывать по айди

у зареганных есть еще как минимум 2 способа оповещения, их можно не только по мылу оповестить

И как это мешает зареганых и не зареганных оповещать по мылу одинаково почему уведломлениям не пофиг на то что зареган он или нет?

так оповещать по мылу их можно одинаково я ж и пытаюсь понять как сделать лучше и что выбрать из приведенных вариантов незареганного только по мылу можно оповестить с этого ремайндера зареганного по мылу + еще 2 канала связи

Так зачем тут упоминать вообще зареган он или нет У вас есть пользователи у них каналы связи все Факт регистрации не меняет ничего в вашем уравнении

Так у тебя логика зависит от реципиента получается

потому что я не хочу перегружать ремайдер синхронизацией с пользователем

Протекание связи и знания о регистрациях намного хуже И где там синзронизация? Хотите синхронные запросы по айди делайте по айди просто каждый пользовтель будет иметь свои канылы и пофиг ремайндеру почему у одного один канал а у другого 3 канала ему какая разница ему важны каналы и только каналы

тогда я не понял вашу мысль вообще