Size: a a a

Software Design/Architecture/Zen

2021 January 22

MG

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

AN

Allan Nettzan in Software Design/Architecture/Zen
А зачем мне каждый раз не в ин-мемори базу писать?
источник

MG

Max Grom in Software Design/Architecture/Zen
Я не знаю. Потому и спрашиваю аргументацию 🙂
источник

AN

Allan Nettzan in Software Design/Architecture/Zen
Да я сам прям точно не могу ответить. 🙈😜
источник

MG

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

SP

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

SP

Sergey Protko in Software Design/Architecture/Zen
Короч все где данные быстро меняются и прилетают новые.

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

SP

Sergey Protko in Software Design/Architecture/Zen
Ещё кейсы полезные где то что надо делать с данными просто красиво ложится на какие-то структурки вроде linked list и у тебя уже есть рэдис
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Ну или тарантул (хотя если так то врядли "уже есть" будет аргументом)
источник

MG

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

АХ

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

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

SP

Sergey Protko in Software Design/Architecture/Zen
Max Grom
Общие кейсы мне известны. Ну и всегда аргументация с Redis - если потеря данных за 2 секунды не критична. Но это странный аргумент. С таким же кейсом можно и Mongo продавать и говорить про потерю данных на 2 секунды. Это ж не про базу а про доступность. Все просто повторяют 2 секунды как мантру
Ну если требования низкое летенси и неприхотливо в обслуживании (эластик кэш какой)
источник

ак

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

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

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

SP

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

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

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

MI

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

ак

аминоуксусная кислот... in Software Design/Architecture/Zen
Sergey Protko
Все упирается в то что ты будешь делать с данными после. Jsonb неплохой вариант - можно было бы места хранить как мэпу и менять отдельные поля.
После, например, бронировать места, отрисовывать цены - все как обычно. Всякие анализы не предполагаются, только базовый функционал кинотеатра - показать состояние сеанса по занятым местам и ценам, выбрать нужное место и получить его цену, купить на него билет.
источник

ак

аминоуксусная кислот... in Software Design/Architecture/Zen
Sergey Protko
Все упирается в то что ты будешь делать с данными после. Jsonb неплохой вариант - можно было бы места хранить как мэпу и менять отдельные поля.
Насчёт мэпы это в виде:

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

SP

Sergey Protko in Software Design/Architecture/Zen
Marina Ivanova
Здесь не нужно ничего копировать. Есть группа сущностей «схема зала», в неё будут входить таблицы или поля Зал, Ряд, Место. И отдельно есть группа сущностей «сеанс»(бронь, цена и тд). Связь схема зала - сеанс будет один ко многим. Под группой сущностей я имею ввиду набор таблиц и их связей. Чтобы более детально разобраться, надо рисовать схему БД
Ну или jsonb :)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
аминоуксусная кислота
Насчёт мэпы это в виде:

{place_id1: {price: 50, type: vip, status: occupied}, place_id2:...}
в таком духе?
Так а зачем цену держать там?
источник

ак

аминоуксусная кислот... in Software Design/Architecture/Zen
Sergey Protko
Так а зачем цену держать там?
Ну в принципе да, прайс можно отдельно и искать потом цену в прайсе по типу места
источник