DT
я бы написал
select A.*, B.* from A join C on A.b = C.b;
a.b.c_field
Size: a a a
2019 March 04
ID
ну это же будет с заходом в таблицу В
ID
а если с С в В будет не 1к1поле а ФК, и мне в on надо дописать ещё условие?
ID
select A.*, B.* from A join C on A.b = C.b and C.date > '2019-10-10'::date;
ID
ну походу нельзя так?
AK
select A.*, B.* from A join C on A.b = C.b and C.date > '2019-10-10'::date;
с обычным JOIN нет смысла дописывать условия в ON, вы их с тем же результатом можете вынести в WHERE
но модифицировать условия соединения таблиц в ОРМ джанги нельзя
но модифицировать условия соединения таблиц в ОРМ джанги нельзя
ID
Ну смысла писать джоин так то нет, это просто синтаксический сахар, если написать у where условие по которому джоинить - будет сделано то же
ID
Поэтому это дело вкуса
ID
Писать в on или в where
AK
Ну смысла писать джоин так то нет, это просто синтаксический сахар, если написать у where условие по которому джоинить - будет сделано то же
это пока всякие left join не начались, там уже разный результат убдет
ID
Ну в where можно дописать ещё or A.b_id is null
ID
Это все делает запрос в бд одним и тем же способом
ID
И это не важно
ОК
django.db.utils.InternalError: could not load library "/usr/local/lib/postgresql/plpgsql.so": dlopen(/usr/local/lib/postgresql/plpgsql.so, 10): Symbol not found: _AllocSetContextCreateExtendedВесь день протратил не знаю как решить эту проблему
Referenced from: /usr/local/lib/postgresql/plpgsql.so
Expected in: /usr/local/opt/postgresql/bin/postgres
in /usr/local/lib/postgresql/plpgsql.so
ID
Как сделать такой запрос с django orm?
ОК
django.db.utils.InternalError: could not load library "/usr/local/lib/postgresql/plpgsql.so": dlopen(/usr/local/lib/postgresql/plpgsql.so, 10): Symbol not found: _AllocSetContextCreateExtendedВесь день протратил не знаю как решить эту проблему
Referenced from: /usr/local/lib/postgresql/plpgsql.so
Expected in: /usr/local/opt/postgresql/bin/postgres
in /usr/local/lib/postgresql/plpgsql.so
это когда пытаюсь миграцию запустить
AK
Ну в where можно дописать ещё or A.b_id is null
ноуп.
смотрите вы соединили две таблицы, для каждой левой части нашлась правая часть, и потом применяете к ним условие в WHERE ограничивающие выборку, это отсеит часть результатов.
если тоже ограничение на вторую таблицу вынести в ON условие, то джойниться уже будет не исходная таблица, а только часть прошедшая фильтр, в результате будут все записи из первой таблицы, но местами будет NULL вместо данных второй таблицы.
смотрите вы соединили две таблицы, для каждой левой части нашлась правая часть, и потом применяете к ним условие в WHERE ограничивающие выборку, это отсеит часть результатов.
если тоже ограничение на вторую таблицу вынести в ON условие, то джойниться уже будет не исходная таблица, а только часть прошедшая фильтр, в результате будут все записи из первой таблицы, но местами будет NULL вместо данных второй таблицы.
ID
ноуп.
смотрите вы соединили две таблицы, для каждой левой части нашлась правая часть, и потом применяете к ним условие в WHERE ограничивающие выборку, это отсеит часть результатов.
если тоже ограничение на вторую таблицу вынести в ON условие, то джойниться уже будет не исходная таблица, а только часть прошедшая фильтр, в результате будут все записи из первой таблицы, но местами будет NULL вместо данных второй таблицы.
смотрите вы соединили две таблицы, для каждой левой части нашлась правая часть, и потом применяете к ним условие в WHERE ограничивающие выборку, это отсеит часть результатов.
если тоже ограничение на вторую таблицу вынести в ON условие, то джойниться уже будет не исходная таблица, а только часть прошедшая фильтр, в результате будут все записи из первой таблицы, но местами будет NULL вместо данных второй таблицы.
Это логично, правда, но планировщик работает не так
ID
Я тоже надеялся что если там ограничить, то будет быстрее и работать будет не так, но работает так
AK
Это логично, правда, но планировщик работает не так
я не возьмусь говорить за все СУБД
но в постгрешке, в случае OUTER JOIN, указание фильтров в ON и WHERE не тождественно, и используется в том числе намеренно для получения разных результатов
но в постгрешке, в случае OUTER JOIN, указание фильтров в ON и WHERE не тождественно, и используется в том числе намеренно для получения разных результатов