[email protected] писал(а): ↑2020.09.14, 23:52
А разве рассылка и уведомления не разные вещи?)
Хотите делайте одинаковыми, хотите - разными
Это все слова.
[email protected] писал(а): ↑2020.09.14, 23:52
Появился новый товар - уведомление, Новая акция - новость с уведомлением или рассылка.
Вы путаетесь в словах.
Ок.
Есть информация которую нужно доставить пользователю.
А уж как ее донести, хоть робот пусть звонит на телефон.
Так вот этот пакет информации не вижу смысла как-то обрабатывать по особому, потому что для компьютера нет никакой разницы между "новыми акциям", "уведомлениями", ...,
это просто набор байт, с адресом доставки. В адрес доставки, с точки зрения компьютера входит и канал доставки и адресат.
Мало того, у меня система рассылки работает с несколькими smtp сервисами. Решая по разным критериям какой выбрать для вот этого емайл сообщения. по смс тоже самое, шлюз не один. Но это транспортный уровень, в данном контексте можно опустить.
[email protected] писал(а): ↑2020.09.14, 23:52
Подумав, решил обратное. Помимо браузера, почты, смс могут быть и другие каналы: чат, push.
Дело хозяйские. Хоть для каждого пользователя свою таблицу можно заводить.
Вопрос всегда с какой целью, по каким критериям осуществляется выбор решения.
У меня критерии - простота, единообразность, универсальность.
Добавить в мое решение еще хоть какие чудные направление пару констант в словарь, да может класс отнаследовать.
И все. Админка работает, рассыльщик работает.
[email protected] писал(а): ↑2020.09.14, 23:52
но в push могут добавиться, например, иконка.
Это в шаблоне. к механизму доставки сообщений не имеет отношения.
Максимум - статус сообщения, может иметь разное отображение
[email protected] писал(а): ↑2020.09.14, 23:52
У меня Хэш может быть UUID, который и будет уникальным)
Если UUID не связан с содержимым - он никак не решает проблему:
Систему заклинило и она вызывает подсистему рассылки:
Разошли оповещение об акции
Новогодняя скидка!
Не имея хеша на "Новогодняя скидка!" - подсистема рассылки никак не проверит что 5 минут тому отсылала уже это оповещение.
Думаю вы не поняли о чем речь.
Ну, пару раз с десяток тысяч дублей пользователи получат - поймете.
Делать же хеш UUIDом - тоже чревато. Пототому что идентификация сообщения в системе - это отдельная от содержимого сообщения вещь.
Можно конечно их слить.
Например встречал, делают индентификацию пользователя и его емайл. А потом ой, а он хочет сменить емайл. И все, тогда, с точки зрения системы это будет другой пользователь
Требуется добавить емайл - ой, тогда с точки зрения системы у нас новый пользователь
Рисковое решение - идентификация сущности в системе = содержимое этой сущности. Но, дело хозяйское, уверены что так надо - делайте
[email protected] писал(а): ↑2020.09.14, 23:52
Такие поля делаются для понимания и читабельности)) например, что в колонке status будет значить 1? Никто не знает? А 2?
Ну, если пользователи или операторы у вас читают SQL, сами пишут SQL запросы то конечно, это важно.
А так, извините, ерунда какая-то, про "читабельность значений в БД" я до вас ничего не слышал
Только база пухнет, и скорость обработки ощутимо хуже, чем у численных значений.
У меня в админке просто есть средства просмотра, поиска, фильтрации сообщений.
У вас наверное не подразумевается такого UI, и нужно будет вручную SQL запросы писать? тогда наверное да.
Но я правда и в таких случаях просто джойню к словарю.
Но, как хотите так и делайте.
[email protected] писал(а): ↑2020.09.14, 23:52
что вы всё время говорите про рассылку. Разве это одно и то же?)
Или вы сами не понимаете о чем говорите
[email protected] писал(а): ↑2020.09.14, 23:52
Разве подписчики темы и уведомления не разные вещи?)
Путаетесь в словах
Для системы рассылки уведомлений нет никакой разницы.
Есть текст, его нужно доставить пользователю. И все.
За кому нужно - отвечает механизм подписки, как нужно - механизм направлений, каналов, и т.п.
Между уведомлением об акции, отказе в оформлении счета на покупку, поздравлением с днем рождения, сообщением о новом посте в теме, емайлом с токеном подтверждения смены пароля, кодом подтверждения операции по смс, ..., ..., ... - нет никакой разницы по сути.
Подписчик темы это всего лишь пользователь, который там чего-то. Это чего-то систему рассылки уже не интересует.
Сообщение - уведомление - в чем разница то? Для системы рассылки - в чем между ними разница?
Кому доставить, Что доставить, посредством Чего (Какими способом) доставить.
Вот три базовые вещи системы рассылок.
Любой.
Остальное - детали.
Абстрагируйтесь от деталей.
На остальное не вижу смысла отвечать - оценки своего решения, которое работает на этом проекте уже больше года, и подобное работает еще на двух я не заказывал.
Это у вас был вопрос, как сделать. У меня не было
Погуглил чуть, да и сделал. Нужных не нашел, либо простенькие совсем, либо переусложненные с малопонятной мне целью, либо являющие неотделимой частью от остального проекта, CMS, форумного движка, или завязанные на фреймворк (портировать из Laravel например непросто)
Делайте как хотите, а я всего лишь рассказал как я делаю, на основе опыта разработки и поддержки таких решений.
[email protected] писал(а):
Вместо автоикремента будут UUID, поэтому много текстовых полей...
ну да, одно неверное решение имеет последствиями другие неверные решения
Как там, кажется у Гете - сютрук не получится застегнуть правильно, если первая пуговица застегнута неправильно.
Зачем вам UUID?
Не, бывает нужен конечно именно UUID.
Но БД так устроены что они его не любят.
Даже если он нужен, скажем для обмена с внешними системами, то я в таких случаях завожу отдельную таблицу для соответствия UUID и целочисленных ID
Да вроде и не только я.
Их же потом индексировать обычно придется, чтобы джойнить быстро. Индексы получатся жирные.
Читабельность же у них ничуть не лучше чем у целочисленного ID
но надо, вот прям надо и все тут - значит да, делайте с UUID