Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
 Re: Oracle XE: a five years of no progress  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
Флэшбек это оффтоп. Его нет ни в Oracle XE, ни даже в Std. Это EE.
11 ноя 10, 10:36    [9759077]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
а текстовая переменная так и не может быть '', только null?
14 ноя 10, 07:10    [9776295]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Yo.!
Guest
Sgt.Pepper
а текстовая переменная так и не может быть '', только null?

и это правильно, три раза уже тут пережевывали.

Siemargl
Флэшбек это оффтоп. Его нет ни в Oracle XE, ни даже в Std. Это EE.

фрешбэк квери есть в любой редакции
14 ноя 10, 17:56    [9777242]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5031
Yo.!
Sgt.Pepper
а текстовая переменная так и не может быть '', только null?

и это правильно, три раза уже тут пережевывали.
Ради интереса.
Я пропустил первые три серии (лень искать, простите) и у меня практический вопрос, типа "что делают оракловые разработчики, если...".
Дано: есть таблица со строковым полем, на него есть индекс, в поле могут быть пустые значения (или "значение отсутствует" - не важно, как назвать).
Я пишу запрос типа "выбрать всё из таблицы, где значение поля равно параметру".
В db2 я объявляю это поле not null и полагаю, что "отсутствие значения" это пустая строка.
db2
create table tab (col varchar(10) not null, ...)
Мой запрос с параметром par будет выглядеть так:
db2
select * from tab where col=par

Мои варианты решения задачи на оракле:
1.
В оракле я не могу хранить пустое значение в not null поле.
Если я сделаю поле с возможностью хранения null, то мой запрос будет выглядеть так:
oracle
select * from tab where col=par or (col is null and par is null)
Как оптимизатор отнесётся к такому запросу?
Индекс будет использоваться (а если будет, то не full index scan ли получится)?
2.
Объявить поле not null и завести своё "отсутствие значения" в виде, скажем, '*'.
Тогда мой запрос не будет отличаться от дб2-шного.

Вопрос: как всё-таки решают в оракле такую задачу?
Может, есть ещё варианты?
15 ноя 10, 10:48    [9779130]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
tanglir
Member

Откуда:
Сообщений: 28966
Mark Barinstein
В оракле я не могу хранить пустое значение в not null поле.
Если я сделаю поле с возможностью хранения null, то мой запрос будет выглядеть так:
select * from tab where col=par or (col is null and par is null)
неужели в оракле нет аналога тому же mysql-евому <=> ?
15 ноя 10, 12:10    [9779732]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Yo.!
Guest
Mark Barinstein

Вопрос: как всё-таки решают в оракле такую задачу?
Может, есть ещё варианты?


where NVL(col,'*null*') =:par
и соответственно индекс по NVL(col,'*null*')
15 ноя 10, 12:53    [9780119]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
Yo.!
Siemargl
Флэшбек это оффтоп. Его нет ни в Oracle XE, ни даже в Std. Это EE.

фрешбэк квери есть в любой редакции

> alter database flashback on;
Нету, а без него далеко не вернешься.

ЗЫ. Про пустые строки тут срач уже был. Может хватит.
15 ноя 10, 18:00    [9782881]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Yo.!
Guest
Siemargl
Yo.!

фрешбэк квери есть в любой редакции

> alter database flashback on;
Нету, а без него далеко не вернешься.

вернешся, флашбэк квери совершенно другая фича.


SQL> alter database flashback on;
alter database flashback on
*
ERROR at line 1:
ORA-00439: feature not enabled: Flashback Database

SQL> delete from emp where rownum=1 ;

1 row deleted.

SQL> commit ;

Commit complete.

SQL> select count(*) from emp ;

COUNT(*)
----------
999998

SQL> select count(*) from emp AS OF TIMESTAMP (SYSDATE-1/24) ;

COUNT(*)
----------
999999

15 ноя 10, 20:51    [9783786]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Mark Barinstein
Я пропустил первые три серии (лень искать, простите)

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

Mark Barinstein
и у меня практический вопрос, типа "что делают оракловые разработчики, если...".

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

Если рассматривать сферическую задачу в вакууме, то неграмотный новичок, возможно, и попытается придумать "собственное пустое значение", как Вы предлагаете, но самый простой путь - использовать составной индекс.
16 ноя 10, 10:05    [9785292]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5031
softwarer
...Во-первых, поиск "по пустой строке" - крайне редкая операция, вот честно, ни разу в жизни не сталкивался с отчётом вроде "люди с пустыми отчествами".
Если рассматривать сферическую задачу в вакууме, то неграмотный новичок, возможно, и попытается придумать "собственное пустое значение", как Вы предлагаете, но самый простой путь - использовать составной индекс.
Ну, задача найти людей с незаполненными паспортными данными, номерами телефона всё же встречается не так редко.
Причём дело здесь не в индексе даже - по всей таблице только по этому пустому полю редко кто ищет.
Вот сферическая задача: поиск по группе записей типа
select * from customer where gid=:par_gid and passport_ no=:par_passport_no
т.е. я имею индекс по этому(им) полю <gid> и ищу всех в этой группе по номеру паспорта.
Этот же самый запрос я использую для поиска тех, у кого нет паспортных данных.
Если я правильно понял про самый простой способ (простите уж неграмотного новичка :)), это использовать для каждого такого поля дополнительное поле-флаг пустого значения?
16 ноя 10, 10:49    [9785700]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
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, '*'), но это уже больше к проктологам и вынужденным общаться с их продуктами.
16 ноя 10, 11:47    [9786245]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5031
softwarer
Вот в этом месте сферическая задача становится.. антиреальной. Смотрите сами: Вы написали запрос, который ищет в группе человека с некоторым номером паспорта. Допустим, он действительно такой нужен. И теперь хотите этим же запросом найти "людей без паспортов". Согласитесь, это совершенно разные задачи, которые скорее всего будут решаться даже в разных формах.
Ну, это от системы зависит.
Одной формой с вариантом использования:
1. получить список по заданным фильтрам
2. отредактировать / удалить / просмотреть нужный объект или создать новый
я решаю все задачи по ведению таких объектов.
softwarer
Ну а на практике самый простой способ - использовать запрос where gid = :gid and passport_no is null. И этот запрос будет использовать индекс по (gid, passport_no), в том числе для поиска null-ов. Если очень хочется извращаться, конечно, можно писать что-нибудь типа where gid = :gid and coalesce (passport_no, '*') = coalesce (:passport_no, '*'), но это уже больше к проктологам и вынужденным общаться с их продуктами.
Здесь ведь вопрос удобства программирования.
У меня в db2 для строк всегда 1 вариант предиката: ... and passport_no = :passport_no

В оракле же, насколько я понял, надо либо:
* динамику использовать - в зависимости от значения параметра, вбитого в форму, писАть:
... and passport_no = :passport_no
либо:
... and passport_no is null
* зашивать дефолтовое значение в программу (и не ошибиться с выбором дефолтового значения, чтоб потом программу не переписывать) и:
... and coalesce (passport_no, '*') = coalesce (:passport_no, '*')

Я не буду больше спорить, чтобы не затевать четвёртую серию сериала. :)
Если для ораклистов это удобно, или, действительно, встречается редко - тоже можно понять.
16 ноя 10, 12:27    [9786623]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Mark Barinstein
Здесь ведь вопрос удобства программирования. У меня в db2 для строк всегда 1 вариант предиката: ... and passport_no = :passport_no

И как Вы поступаете, когда в этом запросе вообще не нужен фильтр по паспорту? Передаёте null и позволяете ему вернуть пустую выборку? ;-)

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

Дата выдачи с:  [__.__.____]
Дата выдачи по: [__.__.____]

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

where 
issue_date >= coalesce (:issue_date_from, issue_date) and
issue_date <= coalesce (:issue_date_to, issue_date)

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

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

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

А без протокола.. я работал так и я работал эдак, и с Oracle, и с MSSQL. И положа руку на сердце, в случае неоракловых строк геморроя больше, особенно в варианте "в таблице три поля, одно допускает null и не допускает пустые строки, другое допускает пустые строки, но не null, третье допускает и то, и другое, а в форме надо ввести значения для этих трёх полей".
16 ноя 10, 13:18    [9787047]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
softwarer
Mark Barinstein
Я пропустил первые три серии (лень искать, простите)

Не только Вы. Забавно наблюдать, как даже Метелица ... отмечается забавными мыслями "про оракл".

Например?

Я, на самом деле, не считаю себя большим спецом по DB2, хоть работаю с ней больше 10 лет, иногда перечитываю документацию и т.п. Пробелов много; правда, многие вещи на моём месте просто не нужны. (Вот Марк - другое дело, он действительно DB2-спец). Но приходится работать с Oracle, это оказывается намного сложнее, чем DB2, и это меня бесит. Приходится вникать в такие вещи, которые я вообще даже не хотел бы знать и без которых при работе с DB2 обходился и обхожусь. Понятно, для ораклиста они нормальны, а мне как-то не забавно совсем. Ну ладно, я уже смирился. Придётся становиться хотя бы OCP DBA... в следующем году.
16 ноя 10, 13:44    [9787299]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5031
softwarer
Mark Barinstein
Здесь ведь вопрос удобства программирования. У меня в db2 для строк всегда 1 вариант предиката: ... and passport_no = :passport_no

И как Вы поступаете, когда в этом запросе вообще не нужен фильтр по паспорту? Передаёте null и позволяете ему вернуть пустую выборку? ;-)

... and (passport_no = :passport_no or :passport_no_Not_used_flag = 1)
Удобно использовать, есс-но, когда не нужен индекс по искомому атрибуту (есть индекс по gid, например).
Преимущества: в кэше запросов такой запрос всегда один, для последующих таких же запросов не тратится время на парсинг, компиляцию - план доступа и так всегда один.
Сравните с кол-вом различных комбинаций для разных значений параметров при сколько нибудь значительном кол-ве разных атрибутов.
Когда таких запросиков очень много, эти накладные расходы могут становиться заметными.

Моя цель - не затеять флейм, а узнать мнение людей, которые практикой занимаются.
Вашу точку зрения я понял, спасибо.
16 ноя 10, 13:47    [9787334]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Mark Barinstein

В оракле же, насколько я понял, надо либо:
* динамику использовать - в зависимости от значения параметра, вбитого в форму, писАть:
... and passport_no = :passport_no
либо:
... and passport_no is null
* зашивать дефолтовое значение в программу (и не ошибиться с выбором дефолтового значения, чтоб потом программу не переписывать) и:
... and coalesce (passport_no, '*') = coalesce (:passport_no, '*')

Форма, вызывается не очень часто (в масштабах запросов в секунду), количество условий заранее неизвестно. Тут я проголосовал бы за динамику, вплоть до подстановки литералов вместо использования переменных. Меня в Oracle то, что пустая строка - это NULL, уже не особо беспокоит. А вот то, что NULL-ы не индексируются, это настоящая проблема.

passport_no = :passport_no может использовать индекс
passport_no is null не сможет

Функциональные индексы грязно выглядят для решения такой ситуации. Но тут остаётся только развести руками.
16 ноя 10, 13:57    [9787437]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
softwarer
Member

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

Возможно, я ошибаюсь, но мне смутно помнится, что "когда-то давно" у DB2 фактически отсутствовал кэш запросов, а планы просто жёстко прописывались при компиляции ХП либо всегда строились на ходу. Во всяком случае, именно на это я привык списывать повышенное (с моей точки зрения) внимание db2-шников к "статика vs динамика". Или это вызвано другими причинами?
16 ноя 10, 14:06    [9787520]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Victor Metelitsa
passport_no is null не сможет

Ну, если это действительно нужно, никто не мешает создать user-defined индекс, к нему оператор ISNULL() и навсегда решить эту проблему. Но скорее любопытно, какие задачи приходится решать так, что при этом это действительно беспокоит?
16 ноя 10, 14:09    [9787535]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Я привык мерять своей меркой. А у меня к базулькам не бывает больше 200 коннектов. Формами с фильтрами пользуются далеко не все, и не чаще, чем раз в несколько минут (на самом деле, много реже). Данные могут быть десятки миллионов строк. Так что мы могли бы себе позволить даже и литералы. А кеш запросов давно есть. Кажется, это появилось при мне, до 2000-го года, где-то около 5-й версии LUW (тогда это по другому называлось, и сразу после 2-й шла 5-я). (Понятно, что сделать prepare и помнить хендл до дисконнекта можно было и до этого).
16 ноя 10, 14:19    [9787602]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
softwarer

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


Ораклиные базы у нас чужой разработки, с сотнями и тысячами таблиц. Теоретически, вещи типа создания индексов я делать не могу. С другой стороны, это наши данные, и я могу делать любые запросы, какие нужно, никого не спрашивая. Какие именно запросы - заранее предположить не могу. Разработчики далеко, а ещё с ними (некоторыми) очень-очень непросто иметь дело.
16 ноя 10, 14:48    [9787832]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5031
softwarer
Возможно, я ошибаюсь, но мне смутно помнится, что "когда-то давно" у DB2 фактически отсутствовал кэш запросов, а планы просто жёстко прописывались при компиляции ХП либо всегда строились на ходу. Во всяком случае, именно на это я привык списывать повышенное (с моей точки зрения) внимание db2-шников к "статика vs динамика". Или это вызвано другими причинами?
В v2.1 не было global dynamic statement cache, оно в v5 появилось.
Но это не важно.
И сейчас в db2 любят демонстрировать на туче мелких запросов преимущества static над dynamic sql - разница может достигать десятков процентов в производительности.
Даже есть прикольный тул для static profiling: оно нападает на программу, использующую динамику, ловит динамические вызовы и преобразует их в статические, а потом эта же неизменённая программа начинает пользоваться статикой.
И я не думаю, что всё это из-за того, что db2 не умеет нормально с кэшем динамических запросов работать.
Но, конечно, чтобы эту разницу увидеть, надо нагрузку соответствующего характера иметь.
16 ноя 10, 14:54    [9787870]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
softwarer
Member

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

Я не был в такой ситуации и определённо не хочу в ней бывать, но с практической точки зрения - если Вы создадите индексы в своей схеме и будете использовать их в своих запросах, имхо разработчики очень мало что смогут сказать Вам. Собственно, если мне не изменяет память, при соответствующе выстроенных правах они даже не получат шанса эти индексы обнаружить (если те не будут падать, конечно).
16 ноя 10, 15:00    [9787912]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Запрос может пойти по неправильному плану, начать тормозить, начнут пинать разработчиков, они увидят в плане этот индекс и спросят, откуда он взялся. Но дело пойти и хуже - ведь они найдут козла отпущения для своих собственных проблем.
16 ноя 10, 15:09    [9788035]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Victor Metelitsa
Запрос может пойти по неправильному плану, начать тормозить, начнут пинать разработчиков, они увидят в плане этот индекс и спросят, откуда он взялся. Но дело пойти и хуже - ведь они найдут козла отпущения для своих собственных проблем.

"Запрос" - в данном контексте это какой-нибудь из запросов разработчиков.
16 ноя 10, 15:12    [9788066]     Ответить | Цитировать Сообщить модератору
 Re: Oracle XE: a five years of no progress  [new]
const64
Member

Откуда:
Сообщений: 789
Прошу прощенья, что встреваю - но (если я правильно понял из предыдущих сообщений) почему, если DB2 не умеет создавать индексы по функциям - то это для DB2 очень плохо, а если Oracle не может создавать индексы по null полям - то это никому и не надо?
16 ноя 10, 15:32    [9788290]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить