я бы сделал так:
есть набор мест, которые как-то там характеризируются (пускай это будет сектор, ряд и место - на самом деле это неважно) и каждая такая запись имеет свою айдишку:
[Seat]
id
sector
row
number
на сколько я понимаю, покупаются/резервируются места на некоторое мероприятие (матч, концерт и т.д.). соответственно, должна быть таблица этих событий. дл простоты охарактеризируем ее только датой. нам и дата не нужна, но пускай себе будет
[Event]
id
datetime
резервирование или покупка места должна относиться к таблице Seat и к таблице Event:
[Reservation]
id
seat_id
event_id
// another fields
Seat к
Reservation как
one-to-manyEvent к
Reservation как
one-to-many
пользователя можно втулить сюда же, но бы выделил связь с юзером в отдельны сущности:
Ticket как билет и еще одну сущность как факт продажи билета некому юзеру
TicketTransfer. но это уже зависит от вашего сервиса, который вы реализуете
я считаю, что так будет правильно