operation_type это тип операции. Списание или же начисление. От этого на фронте будет вырисовываться определённый текст. PLUS - начисление, SUB, списание, но как я уже и сказал это у меня вызывает вопросы. Ведь даже при списании будет начисление.
Смысл? Правильнее добавлять минус при списании к стоимости покупки, тогда это поле вообще не понадобится, а сумма по транзакциям будет правильной. Ну и на фронте исходя из знака отображать что там нужно...
list_purchase, конечно можно вынести в отдельную таблицу и я понимаю даже почему, но данное поле даже необязательное, оно как примечание. Стоит ли для неважный вещей создавать таблицу?
Вообще странно, что у вас покупка состоит вроде бы из набора итемов, но они нигде не перечислены, кроме как в необязательном поле...
Не будет ли нарушаться принцип KISS?
KISS это не принцип построения структур, это принцип построения кода, понятного для чтения и интерпретации. А изначально вообще принцип построения визуальных интерфейсов. В построении структуры реляционных баз основной принцип - соблюдение нормальных форм (см. ниже).
И как бы Вы реализовали систему списания и начисления баллов? Наверное это самый главный вопрос
Так а какая логика начислений? Надо добавить - делаем апдейт на нужную сумму, нужно списание - делаем апдейт на нужную разницу, в чем вопрос?
Стоит ли делать зависимости? Чтобы сумма бонусов клиента зависела от таблицы покупок
Может где то, в определённом источнике имеется свод информации, касаемо таких решений? Может где то, в определённом источнике имеется свод информации, касаемо таких решений?
Это называется "
нормальные формы". На практике вам будут нужны первая, вторая и третья нормальная форма (например хранение total_purchase нарушает 3 НФ, так как может быть вычислена из объединения с таблицей покупок).
По наименованию полей: Вроде все более-менее норм, единственно что list_purchase и sum_purchase логичнее переставить - purchase_list и purchase_sum, хорошо же начинали с purchase_date, что пошло не так? )
Простой
