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

Question

Вот мои текущие отношения ,

 1. The student can join multiple clubs
 2. The student can join multiple events
 3. The student can make payment for club membership
 4. The student can make payment for event fees

Вот мои дБ для оплаты

 1. Club
 2. Event
 3. Payment

Прямо сейчас, это модель данных, которую я имею в виду, но она выключена

Clubs table
club_id
club_name
membership_fees
description
...

Events table
event_id
event_name
event_fees
date
venue
...

Payments table
club_id
event_id
user_id
amount
payment_method
...

Если пользователь платит сборы за клуб, event_id будет равен 0, если пользователь платит заплата за мероприятие, club_id будет 0. Это правильный способ сделать это?Я хочу иметь возможность запросить историю платежей все в одной таблице.Также я буду использовать laravel для проекта

Answer 1

Отношения между клубами и событиями направлены против пользователя , а не друг против друга.Кроме того, поскольку оба отношения «многие ко многим», вы могли бы воспользоваться двумя таблицами мостов ;один между пользователями и клубами, а другой между пользователями и событиями:

user_clubs таблица:

user_id  |  club_id   |  payment_method
---------------------------------------
    1    |     1      |  'Visa'
    2    |     1      |  'Visa'
    2    |     2      |  'Mastercard'

user_events таблица:

user_id  |  club_id   |  payment_method
---------------------------------------
    1    |     1      |  'Visa'
    2    |     1      |  'Visa'
    2    |     2      |  'Mastercard'

^{Это в дополнение к user, clubs и events таблицам.}

Как вы можете видеть, это позволяет пользователям присоединяться к нескольким клубам и посещать несколько мероприятий, а также позволяет клубам исобытия для размещения нескольких пользователей.Это также полностью устраняет необходимость в таблице payment полностью, перемещая единственный отсутствующий столбец (payment_method) на две таблицы мостов.membership_fees отображается на amount, поэтому он больше не нужен.

Отсюда вы можете запросить все соответствующей информации о конкретном пользователе (или клубе /событие) путем объединения таблиц в вашем запросе.Например, если вам нужна вся информация о пользователе:

SELECT * FROM user
         INNER JOIN user_clubs ON user.id = user_clubs.user_id
         INNER JOIN clubs ON user_clubs.club_id = clubs.id
         INNER JOIN user_events ON user.id = user_events.user_id
         INNER JOIN events ON user_events.user_id = club.id
WHERE user.id = '1'

Это даст вам всю информацию о пользователе;клубы, в которые они входят, события, которые они посещают, соответствующие сборы и то, как пользователь оплачивал эти сборы.

Answer 2

Если я думаю о более глубокой стороне ДИЗАЙНА БАЗЫ.На мой взгляд, дизайн базы данных плохой.

Я полагаю, что ваш платеж должен быть простым.

transaction_id
user_id
transaction_code
amount
payment_method
notes_description
transaction_datetime

Код транзакции должен быть идентификатором или КОДОМ, чтобы "классифицировать" тип платежа.то есть.

Имея это в виду, вы можете создавать столько экземпляров событий, групп, классов, членства и т. д., сколько захотите.Просто добавив новый код или идентификатор.Нет проблем.Централизация ваших платежей в одной таблице.

Answer 3

да, это правильный путь, и пока вы извлекаете запись, вам нужно две функции отношений в вашей модели: одна для события, а другая для клуба.