реализация уведомления пользователей в той же таблице или в отдельной связанной таблице (laravel)

#mysql #database

#mysql #База данных

Вопрос:

у меня есть таблица пользователей и счетов, в которой я хочу отправлять им уведомления о том, что они смогут включать / выключать их. теперь мой вопрос заключается в том, что я должен добавить 5 столбцов, например, в таблицу пользователей и 3 в таблицу счетов, чтобы включить или выключить ее, или создать 2 таблицы, как показано ниже: notification_list и : notification_user , чтобы пользователь мог включать или выключать уведомление из модели пользователя и счета-фактуры. проблема здесь в том, что notification_user будет огромная таблица, как только таблица пользователей увеличится. для каждого пользователя мне нужно добавить как минимум 5 записей. я использую laravel и его таблицы и отношения. поэтому я могу использовать морфологические отношения, но я все еще не знаю, какой из них лучше реализовать внутри таблицы или в отдельной таблице. Спасибо

Ответ №1:

Если это можно переключить глобально для всех счетов сразу

Вам определенно нужно notification_list , но вместо notification_user я бы добавил дополнительный столбец в users таблицу или создал что-то вроде users_preferences для хранения нескольких пользовательских настроек. Создание отдельной таблицы для каждого из предпочтений не кажется хорошим решением

Если это должно быть сделано для каждого счета отдельно

На самом деле вы не можете добавлять дополнительные столбцы в таблицу invoices и users , поскольку вам потребуется иметь один столбец для каждого пользователя.

Вы должны использовать свое решение № 2. Но имейте в виду, что вам не нужно создавать какие-либо записи в таблице, если они не отличаются от поведения по умолчанию. Это означает, что вы добавляете запись в таблицу только тогда, когда пользователь переключает кнопку. Также вы можете удалить эти записи, как только счет-фактура больше не активен. Таким образом, эта новая таблица на самом деле растет не так быстро.

Комментарии:

1. Читая снова, я начал думать, правильно ли я понял ваш вопрос. Вы включаете / выключаете глобально для всех уведомлений о счетах или вы переключаете его для каждого счета отдельно?

Ответ №2:

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

Это основано на том факте, что вам нужно отслеживать только состояние предпочтения (включено или выключено).

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

 $preference1 = 1;
$preference2 = 0;
$preference3 = 0;
$preference4 = 1;
$preference5 = 0;

//the value to save is the integer result of the binary 01001
$preference = 1 * $preference1   2 * $preference2   4 * $preference3   8 * $preference4   16 * $preference5;
//or simply
$preference = bindec($pref5.$pref4.$pref3.$pref2.$pref1);
  

Теперь, чтобы проверить, включено ли определенное предпочтение, используйте побитовое сравнение

 if ($preference amp; 4) { //preference 3 has value 4
    //preference 3 is on.
}

//you can also check multiple prefrences at the same time
if ($preference amp; 5 == 5) { //this is preference 3 and preference 1
    //user has both preference enabled
}
  

Вы также можете использовать это в своем запросе к базе данных

 $users = User::whereRaw("BIT_COUNT('prefrence' amp; 4)")->get();
//this will give you all the users having preference 3 enabled
  

Чтобы добавить больше структуры к этому решению, вы должны объявить константы в своей пользовательской модели

 class User extends Authenticatable
{
    const PREFRENCE1 = 1;
    const PREFRENCE2 = 2;
    const PREFRENCE3 = 4;
    const PREFRENCE4 = 8;
    const PREFRENCE5 = 16;
    //...
}

//This way everything will make more sense like:
$users = User::whereRaw("BIT_COUNT('prefrence' amp; ".User::PREFERENCE3.")")->get();

if ($preference amp; User::PREFERENCE3) {
    //preference 3 is on.
}
  

PS: Убедитесь, что целочисленный размер в базе данных не соответствует вашему номеру предпочтения для сохранения.

Комментарии:

1. Я действительно не понимаю, зачем кому-то это делать, если не использовать систему со сверхнизкими ресурсами. Несколько bit столбцов с правильным названием, подобным receive_invoice_notifications , облегчат чтение вашего кода, чем это.

2. @NoOorZ24 это сделает ваше решение расширяемым (и убираемым) без необходимости изменять структуру базы данных. Вы можете легко добавить новый тип предпочтения только в свой код.

3. я понимаю, к чему вы клоните, я бы просто попытался абстрагироваться от многого из этого, чтобы не заставлять кого-то разбираться с битами