Подскажите пожалуйста где я совершил ошибку. Не получается получить сумму

select sum(T_1.Quantity) as F_1, T_1.StoreBatch_ID as StoreBatch_ID, T_3.Code as F_2 from StoreSubBatches T_1 left join StoreBatches T_2 on T_2.ID = T_1.StoreBatch_ID left join StoreCards T_3 on T_3.ID = T_2.StoreCard_ID where T_3.Code = '2460107160340' group by T_3.Code

А так?

select sum(T_1.Quantity) as F_1, T_3.Code as F_2
from StoreSubBatches T_1
left join StoreBatches T_2   on T_2.ID = T_1.StoreBatch_ID
left join StoreCards T_3   on T_3.ID = T_2.StoreCard_ID
where T_3.Code = 2
group by T_3.Code

Добрый день! Подскажите разницу в одной конкретной ситуации: две сущности (Специальность и Программа_подготовки), связь многие-ко-многим. Цель создать таблицу в которой указывать, что человек имеющий некоторую Специальность, может поступать на некоторую Программу_подготовки. При этом каждый год это соответствие между Специальностиями и Программами_подготовки изменяется и необходимо иметь возможность просматривать это соответствие в прошлом. Вопрос. Корректно ли использовать суррогатный ключ (Спец_ПрогПод_Ид) или составной (Спец_Ид, ПрогПод_Ид)? Почему сейчас, как я заметил,  хорошей практикой является отсутствие идентифицирующих связей?

не хочешь фильм рекламировать?

Не совсем понял предложения 😅

Всем привет!
Кто может подсказать в docker-compose есть mysql и через него меняю файл my.cnf
в my.cnf sql_mode="", делаю SELECT @@sql_mode; и вижу STRICT_TRANS_TABLES, пытался сделать так set global sql_mode='';
все равно STRICT_TRANS_TABLES остается, а когда что-нибудь добавляю в sql_mode все равно STRICT_TRANS_TABLES и дальше мои настройки добавляются, пытался даже через docker-compose sql_mode прописать, ничего не выходить вообще никак не исчезает STRICT_TRANS_TABLES

Потом смотрю вот так SELECT @@GLOBAL.sql_mode; и там пусто, то есть так как я задал в my.cnf
Я так понял что для текущей сессии всегда ставится STRICT_TRANS_TABLES
Как это исправить ?

Отвечу сам себе, ну и если кому любопытно. В общем проблему удалось вроде побороть. Коллеги разработчики определили, что по упомянутым двум таблицам происходили операции с двумя инсёртами в одной транзакции, убрали это. Далее в конфиг слейва были добавлены вот такие параметры:
slave_preserve_commit_order=1
slave_parallel_type =LOGICAL_CLOCK
Далее таблицы при остановленной репликации были дропнуты полностью (до этого я делал truncate, саму структуру таблиц не дропал, возможно еще это влияло), и перезалиты с мастера. Обновляются они не так часто, там рассинхрона не должно было быть. После рестарта и запуска репликации слейв догнал мастера, ситуация стабилизировалась, сейчас проблема не наблюдается. Спасибо всем, кто откликнулся)

Мне тут нужно выбрать индекс для БД для поиска по этажам и бюджетам департаментов. Конкретно: нужно посчитать, сколько департаментов будет на определенном этаже, у которых бюджет меньше 50к.
Бюджеты варьируются от 0 до миллиона, этажи от 1 до 10.

Тут юзается COUNT. Но нужен ли мне clustered или unclustered index?

И лучше будет b+ tree на этаж и бюджет или хэш на этаж? Важна только скорость, место не имеет значения.

Эээ... а о какой СУБД речь-то?

Постгрес

Во-первых, в нём нет кластерных индексов (а то я всё пытался угадать, что это за странное сочетание features, в какой СУБД есть и кластерные индексы, и "дисковые" hash-индексы). ;)
Во-вторых, почему бы не спросить в https://t.me/pgsql ?

Спасибо.

Подскажите, в БД хранятся диапазоны чисел в виде start_n и end_n, мне нужно запросить список значений. Я делаю это в виде

select start_n, end_n from table where (start_n < ${num1} and end_n > ${num1}) or (start_n < ${num2} and end_n > ${num2}) or ...

При таком запросе, так как БД не возвращает конкретное число, приходится уже локально проверять вхождение числа в диапазон и привязывать. Можно ли как то сделать, чтобы результат запроса содержал значение каждого запрашиваемого числа?

СУБД к сжатию данных очень плохо относится.

Да это вообще все надо переделать, это уродец какой-то, а не БД...
Особенно нравится таблица категорий

Group by некорректный

Поле
T_1.StoreBatch_ID

Тоже должно быть в group by

Ты чушь какую-то написал, все корректно, ничего не является.

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

Так что ЛУЧШЕ делать тут идентифицирующую.

Что-то и ты не сечёшь, и коллеги твои лошары.
Транзакция есть суть репликации, составные транзакции никак не могут мешать ей. Это нормально, когда в БД есть сложные составные транзакции, репликация должна при этом работать нормально.

Видимо, у вас эта таблица была сломана ещё ранее либо ломалась в процессе начального создания репликации

Без структуры таблиц и запроса это бессмысленно обсуждать