Реквест на участие звучит как бизнес-правило в процессе какого-то турнира/игры. Но я не об этом спрашивал. Почему именно ин-мемори?

А зачем мне каждый раз не в ин-мемори базу писать?

Я не знаю. Потому и спрашиваю аргументацию 🙂

Да я сам прям точно не могу ответить. 🙈😜

Я не критикую, если что. Мне кажется это хорошим выбором. Просто думал там сходу были какие-то требования, хотел услышать кейс)

Я могу накидать пример кейсов когда ин мемори хорошо подходит - например всяческие кейсы с presence detection где потеря данных за пару секунд не сильно важно (повторят запрос - всеравно обновят и старое уже не актуально) при этом данных не оч много (128 байт примерно но человека) и идеально ложится рэдис какой с sorted sets. А альтернатива например в постгре писать а он такого не любит (когда много пишут и много удаляют). Тупо масштабировать проще

Короч все где данные быстро меняются и прилетают новые.

P.s. тот же рэдис может в коммит лог писать для надёжности но ну его

Ещё кейсы полезные где то что надо делать с данными просто красиво ложится на какие-то структурки вроде linked list и у тебя уже есть рэдис

Ну или тарантул (хотя если так то врядли "уже есть" будет аргументом)

Общие кейсы мне известны. Ну и всегда аргументация с Redis - если потеря данных за 2 секунды не критична. Но это странный аргумент. С таким же кейсом можно и Mongo продавать и говорить про потерю данных на 2 секунды. Это ж не про базу а про доступность. Все просто повторяют 2 секунды как мантру

Возьму 1 заказ на чат-бота в Телеграмме/Вк любой сложности для кейса за символическую плату - Пишите в ЛС 🔥

В феврале подниму ценник 10х

Ну если требования низкое летенси и неприхотливо в обслуживании (эластик кэш какой)

Посоветуйте, пожалуйста, способ реализовать что-то вроде паттерна Прототип в базе данных? Задача создать схему кинозала (ряды, места, типы мест) и копировать эту схему при создании сеанса (и скорее всего изменять ее новыми полями вроде цены, брони). Или другой способ решить эту задачу 😄

Я пока думал создать в базе тип "место" и как-то копировать массив мест из зала в сеансы. Но при этом в зале они точно в другом формате должны храниться (им в таблице залов поля брони и цены не нужны, эти поля должны только к сеансу относиться), и это добавляет сложности.

С бд очень поверхностно знаком, использую PostgreSQL. Может, лучше использовать деревья или JSON?

Все упирается в то что ты будешь делать с данными после. Jsonb неплохой вариант - можно было бы места хранить как мэпу и менять отдельные поля.

Здесь не нужно ничего копировать. Есть группа сущностей «схема зала», в неё будут входить таблицы или поля Зал, Ряд, Место. И отдельно есть группа сущностей «сеанс»(бронь, цена и тд). Связь схема зала - сеанс будет один ко многим. Под группой сущностей я имею ввиду набор таблиц и их связей. Чтобы более детально разобраться, надо рисовать схему БД

После, например, бронировать места, отрисовывать цены - все как обычно. Всякие анализы не предполагаются, только базовый функционал кинотеатра - показать состояние сеанса по занятым местам и ценам, выбрать нужное место и получить его цену, купить на него билет.

Насчёт мэпы это в виде:

{place_id1: {price: 50, type: vip, status: occupied}, place_id2:...}
в таком духе?

Ну или jsonb :)

Так а зачем цену держать там?

Ну в принципе да, прайс можно отдельно и искать потом цену в прайсе по типу места