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

[olegy123]

Я же написал: Там - уникальный индекс. Так вы ещё и индексы не знаете, что ли?
Сейчас-же идите учите все уникальные и не уникальные индексы!

Нет, про уникальные индекс у меня двойка, а вот про конвейеры и группировки - пятерка..

Добавлено спустя 5 минут 23 секунды:
Виталий, как вы могли промахнутся с SQL запросом? С одинаковыми полями в результате? С JOIN - зачем он нужен и когда он применяется? А?
Мне с индексами простительно, но вам?

[vitaly_l]

как вы могли промахнутся с SQL запросом?

Художники, в отличии от программистов - исключают возможность NULL в индексах
( поэтому я и не знал что там "AS" а не "=", т.к. не пользуюсь NULL ).

про уникальные индекс у меня двойка

Я рад, что Вы - это увидели, остальное не имеет значения.

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

про конвейеры и группировки - пятерка

И кстати, там Вы тоже лажали. Это kosteek - случайно сделал почти правильный вариант, а не Вы. А правильным он стал, когда из него убрали всё что в WHERE, т.к. только после ответа ТС - стало понятно, что именно он хотел получить. А до этого вы несли полную ахинею и уверяли что, JOIN ВДРУГ покажет нам разных создателя и редактора в WHERE, там где не NULL. И ещё предлагали включить ID_MODERATOR.

[olegy123]

Художники, в отличии от программистов - исключают возможность NULL в индексах

FOREIGN KEY не может имеет NULL?
Тогда зачем в опциях индекса ON DELETE/ON UPDATE SET NULL?
Проясните мне ситуацию, а то я чувствую что не правильные книжки читал.

JOIN - зачем он нужен и когда он применяется? Зачем и когда необходимо заменить на WHILE во связанных таблицах?

Добавлено спустя 5 минут 45 секунд:

И ещё предлагали включить ID_MODERATOR.

потому что он присутствовал в условии вывода

[vitaly_l]

FOREIGN KEY не может имеет NULL?

Может! Он всё может. Но дикие художники в своих программах - этого ему не позволяют. В смысле: художники не пользуются NULL в БД, у нас там всегда есть реальное значение, задаваемое по умолчанию. ( это не обязательное требование к БД, просто я так делаю и поэтому не знал про as NULL )

JOIN - зачем он нужен и когда он применяется? Зачем и когда необходимо заменить на WHILE во связанных таблицах?

Где хотите там и пользуйте. JOIN - хороший и удобный инструмент. И принципе Вы правильно его предложили, просто изначально мы решали не ту задачу и поэтому появились модераторы и т.д. А While - там вообще ненужен, т.к. он выводит всё что есть в таблице. Короче забейте - всё хорошо, я просто подтрунивал - это позволяет лучше запомнить информацию. Принцип - игры.

[alexs]

Select B в Select A - это плохой подход. Каждый Row A может выборку делать в Select B каждый раз. если Select A - дает 1000 и Select B 2000 - то ловите 2000000 операций.
Еще фокус в том что если Select B даст более одной позиции?

В голой теории возможно вы правы. Но на практике такого не будет. При правильно построенной базе (наличие PK/FK/индексов) сервер выберет только одну запись
Причем во время поиска даже обращения к данным не будет - всё решится на уровне индексов. И во многих случаях это будет даже быстрее, чем через join в основном запросе (так как нет обращения к страницам данных).
С другой стороны оптимизатор FB (а как я понял - там FB) в последних версиях тоже стал умнее. Так что по времени там будет практически равнозначно.

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

JOIN - зачем он нужен и когда он применяется? Зачем и когда необходимо заменить на WHILE во связанных таблицах?

Изначально у JOIN единственное назначение - отделить в запросе связи таблиц от логики самого запроса. Как плюс, JOIN позволяет строить связи один к пустому (т.е. когда в справочнике запись есть, а в основной таблице - нет)
До введения в стандарт этой конструкции СУБД строители извращались вот таки образом (кажется в MS SQL этот рудимен до сих пор остался)

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

where
  a.aa -= b.aa

[olegy123]

Было у меня когда база обрабатывала запрос >20 секунд. Тогда роль индексов плохо понимал. Пришлось в поле решать проблему.
Второй случай, когда поставщик софта требовал новый сервер, дескать 32 ядер загружены под 100% - опыт пригодился, снизил до 5%.