Firebird 2.5: Выбор данных при NULL

[vitaly_l]

Вот так ещё можно изменить запрос:

Код: Выделить всё

WHERE
(EMPLOYEES.EMPLOYEE_ID = CLIENTS.CREATOR OR CLIENTS.CREATOR IS NULL) AND (CLIENTS.CREATOR = CLIENTS.EDITOR OR CLIENTS.EDITOR IS NULL)


[olegy123]

Какие эти? (кстати там нужно брать INNER JOIN (или просо JOIN), а не LEFT)

разве CLIENTS.CREATOR = CLIENTS.EDITOR на всех позициях CLIENTS?

нет - тогда надо join-ить две таблы EMPLOYEES

[kosteek]

У него скорее всего вот это значение не равно друг другу: CREATOR_EMPL.EMPLOYEE_ID = CLIENTS.CREATOR, т.к. оно всегда должно быть равно.

Такое может быть если таблицы не связаны, тогда автор ССЗБ.
Но автор писал:

Создатель записи присваивается при добавлении новой записи в таблицу CLIENTS и по этому в принципе не может содержать NULL

[vitaly_l]

разве CLIENTS.CREATOR = CLIENTS.EDITOR на всех позициях CLIENTS?

Естественно всегда должны быть равны! Он именно это и ищет. Смотрите внимательно запрос:

Код: Выделить всё

EMPLOYEES.EMPLOYEE_ID = CLIENTS.CREATOR AND
EMPLOYEES.EMPLOYEE_ID = CLIENTS.EDITOR


это тоже самое что, и вот это:

Код: Выделить всё

EMPLOYEES.EMPLOYEE_ID = CLIENTS.CREATOR AND
CLIENTS.CREATOR = CLIENTS.EDITOR


Ему нужны 100% совпадения: CLIENTS.CREATOR = CLIENTS.EDITOR... либо NULL (те которые ещё не редактировались создателями).

Соответственно, по логике... помимо создателей, очевидно могут редактировать ещё и например "модераторы"... И вот если модератор редактировал, то его записи 100% не отобразятся и с JOIN - тоже видны 100% не будут.

[olegy123]

Не совсем понял что подразумевается под конвейером.

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

[kosteek]

olegy123, спасибо, понял.

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

Код: Выделить всё

FROM CLIENTS,
     (select * from EMPLOYEES) as CREATOR_EMPL,
     (select * from EMPLOYEES) as EDITOR_EMPL
WHERE CREATOR_EMPL.EMPLOYEE_ID = CLIENTS.CREATOR AND (EDITOR_EMPL.EMPLOYEE_ID = CLIENTS.EDITOR OR CLIENTS.EDITOR IS NULL)

Вот как раз по конвейеру, буду временно выбраны две разные таблицы с одинаковым содержание (CREATOR_EMPL и EDITOR_EMPL не одно и тоже, но взяты с одной таблицы EMPLOYEES), что и решает проблему CLIENTS.CREATOR = CLIENTS.EDITOR

[olegy123]

Ему нужны 100% совпадения: CLIENTS.CREATOR = CLIENTS.EDITOR... либо NULL (те которые ещё не редактировались создателями).

давайте разберем: если

Код: Выделить всё

SELECT CLIENTS.CLIENT_ID,
       CLIENTS.CREATOR,
       EMPLOYEES.EMPLOYEE AS "CREATORLOOKUP",
       CLIENTS.EDITOR,
       EMPLOYEES.EMPLOYEE AS "EDITORLOOKUP",
..

то всегда будут [EMPLOYEES.EMPLOYEE AS "CREATORLOOKUP"] = [EMPLOYEES.EMPLOYEE AS "EDITORLOOKUP"]

если нужно чтобы не редактировались создателем (CLIENTS.EDITOR=NULL ) или редактировались модератором (ID_MODERATOR)
то можно свести в
WHILE CLIENTS.EDITOR=NULL OR CLIENTS.EDITOR=ID_MODERATOR
Но раз CLIENTS.EDITOR может быть ID_MODERATOR и CLIENTS.CREATOR<>ID_MODERATOR
то
[EMPLOYEES.EMPLOYEE AS "CREATORLOOKUP"] = [EMPLOYEES.EMPLOYEE AS "EDITORLOOKUP"] - неверное построение запроса.

опять сводим все к двум таблам EMPLOYEES для CREATORLOOKUP и EMPLOYEES для EDITORLOOKUP

Добавлено спустя 3 минуты 49 секунд:
Должно так сработать:

Код: Выделить всё

SELECT CLIENTS.CLIENT_ID,
       CLIENTS.CREATOR,
       CREATOR.EMPLOYEE AS "CREATORLOOKUP",
       CLIENTS.EDITOR,
       EDITOR.EMPLOYEE AS "EDITORLOOKUP",
       CLIENTS.EDITED,
       CLIENTS.CLIENT,
       CLIENTS.PHONE,
       CLIENTS.ADDRESS,
       CLIENTS.E-MAIL,
       CLIENTS.ANGRY,
       CLIENTS.NOTES
FROM
    CLIENTS AS C
LEFT JOIN EMPLOYEES AS CREATOR ON CREATOR.EMPLOYEE_ID=C.CREATOR
LEFT JOIN EMPLOYEES AS EDITOR ON EDITOR.EMPLOYEE_ID=C.EDITOR
WHERE C.EDITOR=NULL OR C.EDITOR=ID_MODERATOR

[vitaly_l]

[EMPLOYEES.EMPLOYEE AS "CREATORLOOKUP"] = [EMPLOYEES.EMPLOYEE AS "EDITORLOOKUP"] - неверное построение запроса.

Естественно ложное! Разве это может быть иначе? От того что, они записаны в разные переменные они не перестали быть одним и тем-же.

на узлах могут быть разные результаты..

ПРОТЕСТУЮ!!!!!!! там всегда одинаковые результаты. <== это программа, а не гололёд. здесь вам не хоккей!

Но так как название одно и тоже в таблице - то он думает

ПРОТЕСТУЮ!!!!!!! ОН НЕ ДУМАЕТ!!! ОНО ЖЕЛЕЗКА ( пока ещё)

даже если этот источник изменился в цепях конвейера..

Это ещё как? Взяла, ВДРУГ, нагло вышла из цикла и ВДРУГ забыла, что в новой итерации у неё все значения взяты уже новые?
Тогда это БАГ, она не может читать через 111 строк с разными вариациями запросов!!! И ненужно ничего выдумывать!

.

[olegy123]

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

Код: Выделить всё

FROM CLIENTS,
     (select * from EMPLOYEES) as CREATOR_EMPL,
     (select * from EMPLOYEES) as EDITOR_EMPL
WHERE CREATOR_EMPL.EMPLOYEE_ID = CLIENTS.CREATOR AND (EDITOR_EMPL.EMPLOYEE_ID = CLIENTS.EDITOR OR CLIENTS.EDITOR IS NULL)

Вот как раз по конвейеру, буду временно выбраны две разные таблицы с одинаковым содержание (CREATOR_EMPL и EDITOR_EMPL не одно и тоже, но взяты с одной таблицы EMPLOYEES), что и решает проблему CLIENTS.CREATOR = CLIENTS.EDITOR

Будет работать, но по оптимизации не рекомендуют, при больших таблицах может кушать много оперативки при работе и выдавать долгую выборку.
А с JOIN парсеру понятно как будут использоваться данные, и где можно оптимизировать процесс.

Добавлено спустя 19 минут 2 секунды:

[EMPLOYEES.EMPLOYEE AS "CREATORLOOKUP"] = [EMPLOYEES.EMPLOYEE AS "EDITORLOOKUP"] - неверное построение запроса.

Естественно ложное! Разве это может быть иначе? От того что, они записаны в разные переменные они не перестали быть одним и тем-же.

Когда ты на заводе за конвейером и херачишь план, сверху дают команду (сейчас обрезаем NULL) - пришло фура с Array быстренько перегрузил в другую фуру - оставил там NULL. И отправил дальше.
Другой на выдче результата (SELECT комманда) смотрит, что нужно (Array_A[0] как номер,Array_A[1] как номер,Array_B[5] как текст,Array_A[2] как номер,Array_B[5] как текст,...)

на узлах могут быть разные результаты..

ПРОТЕСТУЮ!!!!!!! там всегда одинаковые результаты. <== это программа, а не гололёд. здесь вам не хоккей!

Ну SELECT-комманда видит схему ..Array_B[5] как текст,Array_A[2] как номер,Array_B[5] как текст,. - два раза Array_B[5] как текст - шеф требует, шефу так нравится..

Но так как название одно и тоже в таблице - то он думает

ПРОТЕСТУЮ!!!!!!! ОН НЕ ДУМАЕТ!!! ОНО ЖЕЛЕЗКА ( пока ещё)

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

[vitaly_l]

  CLIENTS AS C
LEFT JOIN EMPLOYEES AS CREATOR ON CREATOR.EMPLOYEE_ID=C.CREATOR
LEFT JOIN EMPLOYEES AS EDITOR ON EDITOR.EMPLOYEE_ID=C.EDITOR
WHERE C.EDITOR=NULL OR C.EDITOR=ID_MODERATOR

Раз мы (не зная броду) ввели новой понятие ID_MODERATOR, то тогда опять не надо никакого JOIN:

Код: Выделить всё

WHERE
EMPLOYEES.EMPLOYEE_ID = CLIENTS.CREATOR AND (CLIENTS.CREATOR = CLIENTS.EDITOR OR CLIENTS.EDITOR = ID_MODERATOR OR CLIENTS.EDITOR IS NULL)


Добавлено спустя 6 минут 23 секунды:

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

теперь у него думает ПАРСЕР... И задумался у него парсер и на 111 итерации, ВДРУГ изменил запрос и пошли кривые ответы. А потом пасер, ВДРУГ перестал думать... И "О ЧУДО!!!" - ВДРУГ снова стал правильно парсить запросы. И что-же ВДРУГ заставило умного ПАРСЕРА так сильно задуматься, что он стал вдруг на 111 итерации иначе парсить? Не иначе как парсер olegy123 - увидал? Бросил парсить и побежал с olegy123 побрататься? Так? Да?

[olegy123]

теперь у него думает ПАРСЕР... И задумался у него парсер и на 111 итерации,

прочитал как ..на 111 эрекции..
Виталий, SQL - это текст, а не программа в битах. Чтобы у EngineDB закрутились шестеренки и на выходе иметь годный ответ. То нужно чтобы твои хотелки в SQL перевели в язык "шестеренок". Этим занимается парсер.
Заметь что имена в самой DB могут сильно отличатся с "символьными".. некоторые DB могут работать распределенно, кластерно и облачно - вот парсер переводит в свой формат.

[Unvictis]

Но заниматься вангинацией - бессмысленно, т.к. нам невидно самой БД.

Вот все данные моей БД (Firebird 2.5):


Как видно из скриншота в запросе отсутствуют как минимум первые две записи из таблицы CLIENTS.

[kosteek]

Unvictis, пробуй этот запрос

Код: Выделить всё

SELECT CLIENTS.CLIENT_ID,
       CLIENTS.CREATOR,
       CREATOR.EMPLOYEE AS "CREATORLOOKUP",
       CLIENTS.EDITOR,
       EDITOR.EMPLOYEE AS "EDITORLOOKUP",
       CLIENTS.EDITED,
       CLIENTS.CLIENT,
       CLIENTS.PHONE,
       CLIENTS.ADDRESS,
       CLIENTS.E-MAIL,
       CLIENTS.ANGRY,
       CLIENTS.NOTES
FROM
    CLIENTS AS C
LEFT JOIN EMPLOYEES AS CREATOR ON CREATOR.EMPLOYEE_ID=C.CREATOR
LEFT JOIN EMPLOYEES AS EDITOR ON EDITOR.EMPLOYEE_ID=C.EDITOR
WHERE C.EDITOR=NULL OR C.EDITOR=ID_MODERATOR

[olegy123]

kosteek
Вспомнил, что при LEFT JOIN .. ON .. могут участвовать только индексные поля, а они находятся отдельно от самой таблицы.. а при SELECT .. FROM .. глубоко может не анализировать, что выборка будет по индексам таблицы..

[vitaly_l]

Как видно из скриншота в запросе отсутствуют как минимум первые две записи из таблицы CLIENTS.

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

Посмотрите первые две записи, там создатель имеет id = 1, а редактор имеет id = 3. Выборка SQL, которую Вы делаете, априори исключает строки в которых РЕДАКТОР <> СОЗДАТЕЛЯ. (JOIN - тут не поможет).

Опишите что вы хотите получить? Какую именно выборку? Что хотите "отбраковать"?