толку!
- зачем отдельная сущность Status?
- место принадлежит и залу, и блоку? бардак будет. надо, чтобы у зала были блоки, у блоков места
- в Showtime массивы убирайте сразу, потом будет больно
статус держет 4-5 варианта для обозначения мест во фронте. То есть всё таки другие статусы мест в сеансах хранить не надо, только проданные ?
какие “другие” статусы? изъясняйтесь исходя из того, что окружающие ничего не знают о вашей схеме и ходе мыслей
Available Unavailable Selected Accessible Blocked for Social Distancing Во "фронте" это будет разное обозначения мест в зале
Если это лабораторная в институте, то нужно делать так, преподаватель порадуется; а так обычно все делают конфиг в приложении типа 0-свободно 10 в резерве итд. или просто поле varchar, куда и пишут статус текстом
это справчник. на схеме рисуется отдельной табличкой, реализуется как ENUM.
Да, в беке это по-любому будет enum и в БД логично так же сделать. В общем, я так понял, не надо хранить ... дублировать записи мест с привязкой к сеансам, с их статусами ? Только проданные билеты
извините, я не понимаю что “не надо хранить”. определитесь с требованиями, всё станет понятно
Обсуждают сегодня