Mark BarinsteinЯ пропустил первые три серии (лень искать, простите)
Не только Вы. Забавно наблюдать, как даже Метелица, которого я уже скоро десять лет как помню как вдумчивого и грамотного db2-щика, отмечается забавными мыслями "про оракл".

Mark Barinsteinи у меня практический вопрос, типа "что делают оракловые разработчики, если...".
Чаще всего (следует читать как "я сходу даже не припомню, случается ли вообще другое") им ничего делать не требуется. Причин этому несколько. Во-первых, поиск "по пустой строке" - крайне редкая операция, вот честно, ни разу в жизни не сталкивался с отчётом вроде "люди с пустыми отчествами". Поиск по null в числовом поле, хоть и редок, но на порядки чаще. Во-вторых, null - практически всегда низкоселективное значение, и попытка искать его по индексу проигрывает если не фулскану, то сканированию по лучшему индексу.

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

Mark BarinsteinНу, задача найти людей с незаполненными паспортными данными, номерами телефона всё же встречается не так редко
Ну, поскольку ни та, ни другая не являются задачей поиска в таблице пустой строки, о её частоте вряд ли стоит говорить :)

Mark BarinsteinПричём дело здесь не в индексе даже - по всей таблице только по этому пустому полю редко кто ищет.
Именно что. Поэтому вопрос про индекс и отношение оптимизатора в общем малоактуален.

Mark BarinsteinЭтот же самый запрос я использую для поиска тех, у кого нет паспортных данных.
Вот в этом месте сферическая задача становится.. антиреальной. Смотрите сами: Вы написали запрос, который ищет в группе человека с некоторым номером паспорта. Допустим, он действительно такой нужен. И теперь хотите этим же запросом найти "людей без паспортов". Согласитесь, это совершенно разные задачи, которые скорее всего будут решаться даже в разных формах. Соответственно, "этим же" становится неконструктивным, риторическим условием "для достижения нужного результата" - как, знаете, в конкурсах пишут такие условия, которым заведомо соответствует заранее назначенный победитель и только он.

Ну а на практике самый простой способ - использовать запрос where gid = :gid and passport_no is null. И этот запрос будет использовать индекс по (gid, passport_no), в том числе для поиска null-ов. Если очень хочется извращаться, конечно, можно писать что-нибудь типа where gid = :gid and coalesce (passport_no, '*') = coalesce (:passport_no, '*'), но это уже больше к проктологам и вынужденным общаться с их продуктами.

Mark BarinsteinЗдесь ведь вопрос удобства программирования. У меня в db2 для строк всегда 1 вариант предиката: ... and passport_no = :passport_no
И как Вы поступаете, когда в этом запросе вообще не нужен фильтр по паспорту? Передаёте null и позволяете ему вернуть пустую выборку? ;-)

Марк, Вы произнесли именно те ключевые слова - "фильтр" и "динамически" - которые я надеялся услышать, говоря "согласитесь". Чтобы потом отметить одну тонкость. Действительно, запрос вполне может быть один тогда (и в общем-то только тогда), когда к нему применяется некий глобальный фильтр. Но если этот фильтр динамический (что примерно в 100% случаев - единственно профессиональный метод, во всяком случае для Oracle) - разницы нет, один раз научить компонент вовремя подставлять is null не стоит и минуты обсуждения. Если же фильтр таки статический, то рассмотрев типичный QBE-интерфейс (а другой для статики не годится), мы увидим нечто вроде


и соответственно sql:


И теперь, если мы попробуем добавить в фильтр строковое поле (два варианта - не нужен поиск по пустым значениям, нужен поиск по пустым значениям), как-то так окажется, что в оракловом случае sql и передача параметров кодируются не сложнее, а то и проще.

Mark BarinsteinЕсли для ораклистов это удобно, или, действительно, встречается редко - тоже можно понять.
В таком варианте это действительно встречается редко. А с отмиранием Oracle Forms с его жёсткой статикой, полагаю, окончательно потеряет актуальность.

А без протокола.. я работал так и я работал эдак, и с Oracle, и с MSSQL. И положа руку на сердце, в случае неоракловых строк геморроя больше, особенно в варианте "в таблице три поля, одно допускает null и не допускает пустые строки, другое допускает пустые строки, но не null, третье допускает и то, и другое, а в форме надо ввести значения для этих трёх полей".

Марк, вряд ли кто-либо будет спорить с преимуществом кэша запросов, равно как и с тем, что при всём богатстве выбора большинство фильтров таки идёт по типовым сценариям. То есть, имхо, накладные расходы на построение, скажем, 500 хороших планов (из которых штук 20-40 надёжно закрепятся в кэше) имхо просто несравнимы с затратами на выполнение 50'000 запросов по одному и тому же универсально-плохому плану.

Возможно, я ошибаюсь, но мне смутно помнится, что "когда-то давно" у DB2 фактически отсутствовал кэш запросов, а планы просто жёстко прописывались при компиляции ХП либо всегда строились на ходу. Во всяком случае, именно на это я привык списывать повышенное (с моей точки зрения) внимание db2-шников к "статика vs динамика". Или это вызвано другими причинами?

Victor Metelitsapassport_no is null не сможет
Ну, если это действительно нужно, никто не мешает создать user-defined индекс, к нему оператор ISNULL() и навсегда решить эту проблему. Но скорее любопытно, какие задачи приходится решать так, что при этом это действительно беспокоит?

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

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