Ну вот смотрите. У вас есть комплектующие. Каждая такая штука имеет по меньшей мере один интерфейс для соединения. Итого, у тебя появились сущности "комплектующие", "интерфейс", связаннные отношением многие ко многим. Пример состояния БД:

Комплектующие
Блок питания
Видеокарта

Интерфейс
12 пин
4*6+2

Интерфейс комплектующих
БП 12 пин папа
БП 4*6+2 папа
ВК 12 пин мама

БП и ВК могут быть соединены (совместимы), если у них один интерфейс (в нашем примере 12 пин), один из них папа, другой мама

В нашем примере БП и ВК могут быть соединены по интерфейсу 12 пин папа/мама

Кажись понял, спасибо!

Всем привет, мне тут в тестовом задачу по SQL скинули, а мой максимум это простые SELECT. Может можете, где максимально быстро добрать знаний.
Я на datacamp проходил курс, но там вроде такого не было. На sql-ex как-то yt понятно показалось

Дана следующая схема данных (см. рис.)
whs_id – id магазина
frmt – id формата магазина
frmt_name – название формата магазина
trn_id – id транзакции
acc_id – id клиента
trn_date – дата транзакции
total – сумма транзакции
art_id – id товара
qnty – количество товара
value – стоимость товара
Для данной схемы напишите следующие запросы:
- Для каждого клиента выведете магазин, в котором он совершил
первую покупку, и ее дату;
- Выведете клиентов, которые не посещали форматы «У Дома» и
«Гипермаркет» более 8 недель и формат «Авто» более 4 недель;
- Выведете клиентов, у которых 80% чеков содержат от 10 шт. каждого
товара в чеке.

У кого то есть опыт посторонние системы очередей , которая под собой бы имела обычный mysql или postgresql? Интересует какие проблемы могут возникнут ь

Ну значит, не сдал, чё...

ну так а как сдать

время до отправки читать книги: 3,2,1...

Книги, sql-ex и подобное 👍

Ну не большой у меня опыт, но я точно знаю, что все современные системы очередей делают реализации БД для сообщений сами,
традиционные СУБД для этого не очень поворотливые, шустрые.
Во-первых, сообщение — это абстрактный кусок данных, не формализованый. Просто байты грубо говоря.
В РСУБД же всё не так — там нужна формализованность.
Кроме этого, для очередей сообщений важно журналирование, для durability. Но только для него.
Журналирование же в СУБД часто НЕ только для durability и сложнее, а значит, медленнее.
НУ и вот моё впечатление, что чтобы иметь durability с одной стороны, но делать это быстро с другой,
современные очереди сообщений почти все делают свою собственную маленькую СУБД специализированную для сообщений.
Так быстрее.
Хотя конечно могут и внешнюю СУБД использовать.

Очень интересно. Это же взгляд с точки зрения производительности ? В очередях не нужны checkpoints ? Это про это?

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

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

Поэтому наверное check point тут - последний запуск очереди, а более не нужно.

Но я могу ошибаться

At-least-once / at-most-once. Предположим, Subscriber 1 взял себе сообщение в работу, почле чего проходит некоторое время T, превышающее ожидаемое время на обработку сообщения, после которого возникает дилемма: либо считается, что subscriber 1 умер, и сообщение освобождается для subscriber 2, либо сообщение вообще никому больше не отдается. При этом subscriber 1 мог просто затупить, либо T было выбрано неправильно. В целом это решается распределенным локом или его использованием самого сообщения в качестве такового, когда subscriber 1 постоянно обновляет запись "я всё еще обрабатываю мессадж Х", а при отсутствии обновлении в течении T2 (значительно меньше T) считается, что он умер https://medium.com/ayte-io/distributed-locks-semaphores-again-36d35c36b21e

ping/pong для поддержания ws соединения какой-то получается 😅

(ушел читать как работают вебсокеты на низком уровне)

Та шо там читать, как Tcp соединение не закрывающееся

а начинаются с http пакета

Я не о реализации самого ws, а о том, как проверяют фактически сдох юзер на другом конце “провода” или нет, тупо играют в пинг понг, собственно как вы и описали, если вдруг ответа не было в течении какого-то времени, считается что “оппонент” умер, и закрывается связь)