GoS – новый формат хранения данных площадки

Любой разработчик билетной системы обязательно сталкивается с одной типичной задачей – каким образом хранить данные о местах. Так и мы в seatmap.pro долго выбирали, как же хранить схемы.

Сущности в билетных системах делятся на:

  1. General Admission (GA) – либо сектора без мест, либо со свободной рассадкой
  2. Назначенные конкретные места (там где на билете будет написано сектор-ряд-место)

Обычно разработчики идут по пути генерализации модели данных. Описывая самую сложную из структур и пытаясь уместить туда все остальное. Например, самая частая модель данных для площадок это нотация SRS включающая в себя 3 уровня – Section/Row/Seat. Для концертных и спортивных площадок это наиболее типичный вариант, т.к. он позволяет уникально идентифицировать каждое место. Конечно, существуют и другие варианты, которые отражают специфику конкретной площадки. К примеру, большие стадионы могут добавлять 4 уровень вложенности – имя входа на стадион (Enterance). 

Другой характерный тип площадок – клубы и небольшие площадки. 

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

  1. Столик целиком как одно место
  2. Столик по местам без выбора места
  3. Столик с выбором мест

При таком типе адресации все остальные типы, например столики, могут быть описаны как сектора с одним рядом, либо как ряды одного сектора. Так или иначе для клуба чаще всего хватает уровня вложенности 3  для маппинга сущностей.

Ограничения.

Как мы видим, в рамках одной системы, фактически любую площадку можно описать 3мя вложенными сущностями. Всегда бывают исключения, но они легко обходятся либо использованием дополнительных полей в описании (так каждый сектор может содержать имя входа), либо пустыми сущностями (столик как сектор или столик как ряд)

Существенные ограничения начинают возникать при передачи данных о площадке при реализации билетов другими платформами через API. Сложности при интеграции  систем начинаются с первых шагов маппинга сущностей. Несмотря на то что системы продают билеты на одну площадку нотации могут отличаться и это вызывает определенные сложности.

Универсальный формат (GoS)

После множества различных реализаций мы пришли к универсальному формату хранения и передачи данных – GroupOfSeats (GoS). Само понятие GroupOfSeats может описывать любую комбинацию мест, либо GA зон. Один GoS может содержать в себе либо любое количество вложенных GoS, либо места.

SRS нотация может быть описана в GoS как:

  • GroupOfSeats (type=section)
    • GroupOfSeats (type=row)
      • Array of seats

Типы групп мест могут быть расширяемыми.

Пример записи клуба

  • GoS (type=floor) // этаж
    • GoS (type=zone, ga=true/false) // зона VIP, танцпол
      • GoS (type=table, ga=true/false) // столик
        • Array of seats

Сейчас в seatmap.pro мы храним данные в GoS нотации, но конечно поддерживаем SRS для обратной совместимости. GoS подход позволяет нам интегрироваться в любую систему.

Комментарии

Другие публикации