Как выполнить подзапрос в SQL (SELECT с передачей параметра из основного запроса?

Насколько я понимаю, т.к. подзапросы выполняются снизу вверх

Нет.

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

Это не может быть проблемой. В крайнем случае, если вылезает join multiplying, подсчёт может быть убран в CTE/подзапрос. Впрочем, скорее всего orders.id - синтетический первичный ключ, тогда COUNT(DISTINCT orders.id) снимает эту проблему.

Ошибка SQL HASMGR?

А попробуйте прочитать весь ответ, а не первые две строки.. особенно вот это: сперва надо разобраться с логикой зависимостей таблиц.

Почему count(extract не стакается и чем это заменить?

а можешь вот это перефразировать? кажется это на ельфийском

?? что тут непонятно. Функции передаются значения поля. Она считает, сколько из переданных в группе значений не являются NULL. Всё.

Если birth_date содержит корректное не NULL значение, то extract(month from birth_date) тоже будет корректное не NULL. Если же поле содержит NULL, то и выражение даст NULL. А потому что count(extract(month from birth_date)), что count(birth_date) дадут абсолютно один и тот же результат.

Различаться они могут только в одном случае - если birth_date содержит НЕкорректное значение, причём это не NULL, и настройки не приводят к ошибке при вычислении функции (генерируется предупреждение). Вот тогда значение выражения будет NULL, и оно не будет посчитано, в отличие от непосредственно значения поля (оно пусть и кривое, но всё же не NULL).

Почему count(extract не стакается и чем это заменить?

вы говорите что проблема вероятно в том что в birth_date есть значения с которыми COUNT() не работает

Да ладно! где это я что-то подобное говорю???

Почему count(extract не стакается и чем это заменить?

а если я хочу чтобы селект выдал одну колонку?

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

Почему count(extract не стакается и чем это заменить?

Функция COUNT() считает количество не-NULL знfчений, а потому

select count(extract(month from birth_date)) ..

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

select count(birth_date) ..

Как подключить интернет Интернет-Роутер-Свитч?

А вот касательно dhcp ... мне надо будет на коммутаторах его включать?

На коммутаторе нет никакого DHCP. А то, что есть с фрагментом DHCP в наименовании параметра - лучше не трогайте.

Как в Postgresql хранить координаты карт?

При свободном вводе (а описание предполагает именно его) - простое текстовое поле. Для точки там записываются координаты, иначе наименование объекта, которое может быть как точным (скажем, конкретный адрес), так и приблизительным.

Триггер на удаление записей в связанной таблице?

Внешний ключ с каскадным удалением. Никаких триггеров для этого не требуется.

Как правильно создать связь между таблицами в MySQL?

accounts - это аккаунт пользователя. При регистрации пользователь выберет с помощью чекбокса какой тип аккаунта он хочет создать: individual (физическое лицо) или cargo_carriers (фирма перевозчик).

Это явная ошибка. Должен существовать аккаунт пользователя. Должен существовать аккаунт фирмы. А вот пользователь может быть либо только самостоятельным пользователем, либо ещё и представителем фирмы. И в аккаунте фирмы аккаунт пользователя будет указан как аккаунт представителя.

Запись json в БД?

Пытаюсь добавить json в БД. Добавляется это:

Вы добавляете не JSON, а строковый литерал. То, что внутри у него JSON, нигде не было указано. Отсюда и обрамляющие кавычки, и квотирование внутри,

Используйте явное приведение типа.

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

Ошибка при создании процедуры..?

delimiter // - это синтаксис MySQL. Ваш PostgreSQL его понимать отказывается...

В чём принципиальная разница двух запросов?

ComodoHacker,

Об эквивалентности нужно говорить именно в контексте конкретной схемы данных, если мы решаем конкретную задачу, а не теоретизируем.

Если так подходить, то просто смотрим на изначальные запросы, обнаруживаем, что структура выходных данных различна, и ставим штамп "Неэквивалентны". Чистая практика, никакого трёпа. Кстати, именно с этого я и начал.

А вот всё остальное - это и есть теоретизирование.

Возможно, Вы как-то иначе понимаете эквивалентность запросов. Для меня эквивалентны - это "дают одинаковые выходные наборы при любых одинаковых входных данных". WHERE IN и WHERE EXISTS - эквивалентны. LEFT JOIN с условием по правой таблице в ON и такой же с условием во WHERE и дополнительным OR IS NULL - эквивалентны. А показанные автором - нет.

В чём принципиальная разница двух запросов?

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

Что, собственно, и наблюдается - достаточно полю id потерять уникальность, и эквивалентноси конец, да? Так не обманывайте себя, её не было.

В чём принципиальная разница двух запросов?

:facepalm: У Вас частный случай - id является уникальным полем.

В чём принципиальная разница двух запросов?

galaxy,

С поправкой на лишнее поле, запросы логически идентичны

Запросы возвращают различное количество записей. Соответственно любые попытки объявить их логически идентичными - заведомо ошибочны.

Или Вы как-то ну очень иначе понимаете идентичность.

Как удалить запись в таблице через 7 дней?

Зашедульте на сервере (в том же CRON) периодическое (скажем, раз в минуту) удаление записей старше недели. И тогда вообще никакого кода в приложении не потребуется.

В чём принципиальная разница двух запросов?

galaxy,

А где там разная логика? или я чего-то не вижу?

Вероятно, не видишь.

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

Бизнес и продажа фичей важнее качества кодовой базы?

Менеджмент и продажа приносят прибыль.
От разработки - одни убытки.
Задача бизнеса - увеличение прибыли и снижение расходов-убытков.
Поэтому менеджмент в шоколаде, а программисты ... ну ... в общем, не в фаворе.

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

В чём принципиальная разница двух запросов?

В чём принципиальная разница двух запросов?

В том, что они реализуют различную логику и возвращают разные данные. Даже структура различается. На этом фоне всё остальное несущественно.

Какой из запросов будет иметь большую деградацию по мере роста количества данных.

Второй - WHERE IN (subquery) обычно наиболее медленный из альтернативных вариантов, и чем больше массив данных, тем заметнее разница.. а самый быстрый обычно WHERE EXISTS.