Добрый вечер. Подскажите как лучше поступить.

Понимаю, что логика не должна опираться на бд, но все же.

Есть 3 таблицы: products, sizes, product_prices

Products: id, name (все продукты, например: пицца, бургер)
Sizes: id, name (все размеры для всех продуктов, например 25см, 30см, большой, маленький)
Product_Prices: product_id, size_id, price

Итого получается, что 3 сущности как таковые: Product, Size, ProductPrice.
У product'a есть доступные ProductPrice.

От клиента мне приходит id продукта и id размера. Правильно ли? При таком подходе мне необходимо проверить, есть ли такая связь у них через сущность ProductPrice.

Как бы вы сделали?

Ну вот "можно что-то потерять" - это для меня уже не про продакшен

Ещё раз, Фил. Если мне нужно дэшборды строить с агрегацией данных для принятия решений, то вполне продакшен. Да даже если Алерты. Нужно смотреть

вам лучше в sql.ru или dba_ru

Угу, я понял...

Здравствуйте!

Подскажите, пожалуйста, в каком виде лучше записывать требования, если они описывают последовательность действий системы - как одно крупное требование или отдельное требование на каждое действие?

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

Но, если не разделять, вполне может выйти одно большое требование "алгоритм работы системы")

Так реплика тоже вносит latency ;)

Но меньше и предсказуемо (можно закрыть железом)

И так и так.
Одно крупное описывает всю систему в целом. Которое декомпозируется  до отдельных сервисов, работа которых описывается отдельно.

Так а как физику железом закрыть? :) Если репликация асинхронная, то будут расхождения с мастером, если синхронная - она будет тормозить мастера(пока реплика не сделает ack)

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

Если надо список функциональных требований к системе, он достаточно просто оттуда генерируется.

Ну можно латенси на канале снизить сильно, почти до скорости обмена с ram.

Для многих задач может подойти и асинхронная
Ack от чего зависит?

Ключевой момент. Вариантов не много. Аналитическая нагрузка непредсказуема, задержку на репликацию можно расчитать. От железа зависит. Реплика может быть в соседнем ЦОДе или в той же стойке

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

Желательно, чтобы CDC настраивали не базисты, а другие инженеры, чтобы они могли оппонировать

звучит как фантастика :) понятно, что есть rdma, но даже с ним ноду придется ставить рядом и втыкать infiniband

Есть ещё такая компания как Т-системы. У них есть технологий по 100 гигабит в секунду гонять на тыщу километров и более.

Хитрое мультиплексирование на темных волокнах.
Вроде бы как до терабита на волокно собирались сделать.

Это по данным на позапрошлый год.

не стоит путать полосу пропускания и задержку

т-платформы?