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

Откуда: SPb
Сообщений: 5488
mayton
Сергей Арсеньев
пропущено...

Забавно, но NULLы можно заставить хранить и ORACLE в составном индексе.
Как и в PG добавить в индекс where ... not null и получить как в Oracle.

Спор по этому поводу яйца выеденного не стоит.

NULL-s можно заменить на свою волшебную константу и использовать через NVL.
При этом мы получим как бонус индексирование.

Но я-бы предложил другой подход. Как известно (ох как я люблю эту фразу!)
или "есть общепризнанный факт" что индекс эффективен когда объём выборки
не превышает 7%.

Или еще меньше. Я уж не помню. В разные времена эта цифира была разной.
И чем больше становились базы - тем меньше была эта пропорция.

И вобщем-то принудительное индексирование NULL тяготеет к переосмыслению
этого принципа.

Мы должны индексировать ПОЛЕЗНОЕ.

А пустота - это бесполезное.
если оно бесполезное - зачем же его используют?

Сообщение было отредактировано: 29 фев 16, 18:11
29 фев 16, 18:10    [18878852]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 53004
SergSuper
если оно бесполезное - зачем же его используют?

Это вопрос к архитектору. Возможно поиск WHERE field IS NULL
следовало-бы переделать WHERE field = 'somevalue'
и тогда вопрос звучал бы по другому.

Но кто-то упорно делает ставку на ценность пустых полей
в кортеже.

Вобщем... я признаю что поиск WHERE field IS NULL имеет место быть.
Как анализ. Или агрегация чего-то..

Но как вы себе представляете OLTP транзакцию с таким поиском?

Априори я напоминаю что NULL неуникален и запрос может
вернуть много полей для нашей OLTP транзакции.

И зачем нам нужна OLTP транзакция с неуникальной селективностью?
29 фев 16, 18:34    [18878970]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54794

mayton
Априори я напоминаю что NULL неуникален и запрос может вернуть много полей
для нашей OLTP транзакции.

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

Posted via ActualForum NNTP Server 1.5

29 фев 16, 18:49    [18879052]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
mayton
Вобщем... я признаю что поиск WHERE field IS NULL имеет место быть.
Как анализ. Или агрегация чего-то..
вот мне как-то пришлось мигрировать с одной схему в другую практически все таблицы, ключи использовались составные естественные, где nullов было порядочно. Например [код+дата окончания действия]
таблиц порядка 4000, вручную делать новые индексы нереально
вот меня сильно тогда подвела неиндексированность nullов
автор
Априори я напоминаю что NULL неуникален и запрос может
вернуть много полей для нашей OLTP транзакции.
не только первичные ключи индексируются

Сообщение было отредактировано: 29 фев 16, 19:16
29 фев 16, 19:13    [18879155]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
mayton
SergSuper
если оно бесполезное - зачем же его используют?

Это вопрос к архитектору. Возможно поиск WHERE field IS NULL
следовало-бы переделать WHERE field = 'somevalue'
и тогда вопрос звучал бы по другому.

Но согласись хранить somevalue вместо пустоты там где не введены данные - это тот еще архитектурный подход.

А для того, чтобы найти строки, в которых до сих пор не заполнили определенное поле. Вполне себе осмысленная и не бесполезная операция.
1 мар 16, 11:47    [18881371]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 53004
Я просто продавливаю свой аргумент в пользу CRUD/OLTP.
1 мар 16, 12:08    [18881493]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 53004
Коллеги. Давайте немного отвлечемся и вспомним SQL и основы проектирования БД.

Вспомним картинку. Нарисована таблица. Где часть полей - ключевые. Инстанциированы.
Часть полей REQURED (NOT NULL). И часть полей - NULLABLE. Опциональные поля.
Таких полей может быть много. Яркий пример - географические справочники и классификаторы.
Там вечно - вакуум. И еще много подобных generic-примеров. Незаполненные
анкеты физлиц. e.t.c.

Что такое есть NULL с точки зрения реляционной алгебры?
Это не константа.
Не ноль.
Не false.
Это дырка. Выколотое значение. В таблицах иногда его обозначают как прочерк. Общая
суть - пустое значение элемента в кортеже. Неинициализированное. Базы данных еще
на этапе создания предполагают что не все поля могут быть инстанциированы. Это разумно.
Данных нет. И таких дырок может быть ... ну 25% от общего количества. А то и больше.
Всё зависит от рода информации.

С точки зрения системы хранения NULL-s - это вакуум. Его можно наделять разными
поисковыми смыслами, но в первую очередь, исходя из принципов Реляционной алгебры
это полное отсутствие информации.

Разумеется storage-engines могут учитывать эту особенность или нет. ЕМНИП Oracle
не резеревирует место в db_blocks в таблицах для пустых значений. И это разумно.

Давайте зададим вопрос. Разумно-ли аллоцировать место в индексах для NULL's?
Особенно беря в расчёт процент пустых значений. Представьте себе константу
которая "лупит" по B+Tree, порождая только листовые значения со ссылкой на
data_rows.

Давайте зададим другой вопрос. Индекс строиться для очень быстрых операций
извлечения инфы. Какой смысл очень быстро извлекать пачку NULL-s? Может
это неверный дизайн и эти загадочне NULL-s rows имеет смысл положить
в таблицу-отстойник?

Напоследок хочу сказать что опция VIRTUAL COLUMN в Oracle позволяет
трансформировать любое значение для индексации. Но оно того стоит?
1 мар 16, 13:41    [18882138]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54794

mayton
И таких дырок может быть ... ну 25% от общего количества. А то и больше.

Дальше можно не читать. Так любому значению можно от балды назначить любой удобный процент
распределения и объявить, что его включение в индекс бессмысленно. Причём с тех же самых
доводов.

Posted via ActualForum NNTP Server 1.5

1 мар 16, 13:51    [18882222]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
mayton
Давайте зададим вопрос. Разумно-ли аллоцировать место в индексах для NULL's?

не смотря на то, что NULL это отсутствие значения, в компьютере как-то все же приходится хранить, есть значение или его нет (null).
Для этого используются индикаторы. Например некий бит = 0 - значение есть. бит = 1 - значения нет, т.е. null.

Так что хранить хотя бы 1 бит на null все же приходится.

Кроме того, сам null точно так же равноправен, как и другие значения, например 1, 2, 3.
Представьте себе миллион записей с равномерным распределением значений 1,2, 3. Создание индекса по этим значением вас не напрягает? А поиск where field = 1 ?
А теперь добавим к 1, 2, 3 так же равномерно распределенное null (т.е. получается по 25% на каждое значение - 1, 2, 3 и null).
Чем null провинился, что мы его выкинем из индекса?
Чем отличается
where field = 1
от
where field is null ?
По-моему, оба этих условия поиска равноправны. Но в итоге что - для field = 1 индекс будет использоваться оптимизатором, а для field is null поедет фуллскан?
1 мар 16, 14:04    [18882315]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 53004
А какие DBMS индексируют null by default.

Дайте мне список pls. Я просто хочу владеть информацией хотя-бы на уровне названий.
1 мар 16, 14:43    [18882600]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
mayton
А какие DBMS индексируют null by default.

Дайте мне список pls. Я просто хочу владеть информацией хотя-бы на уровне названий.

MS SQL
1 мар 16, 17:35    [18883785]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Ivan Durak
mayton
А какие DBMS индексируют null by default.

Дайте мне список pls. Я просто хочу владеть информацией хотя-бы на уровне названий.

MS SQL

да и DB2
1 мар 16, 17:41    [18883820]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Firebird
1 мар 16, 17:43    [18883832]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
mayton
А какие DBMS индексируют null by default.
Caché (в некоторых случаях в индексе значение маркера для NULL может быть другим).
1 мар 16, 17:56    [18883890]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 53004
Ок. Спасибо. Почитал про DB2. Насколько я понял, индексация NULL - это опция про создании
индекса. Верно?
1 мар 16, 18:00    [18883911]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 53004
Почитал оракловый форум. Workarounds.

Здесь - предлагают partitioning
https://www.sql.ru/forum/1102209/indeksirovanie-tolko-zapisey-s-null

Тоже интересно. При биткартовый индекс и прочее.
https://www.sql.ru/forum/105511/indeks-i-null-znachenie


Пишет к сож. ныне покойный Андрей Криушин. Царствие ему...
1 мар 16, 18:10    [18883946]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
mayton
Что такое есть NULL с точки зрения реляционной алгебры?
Это не константа.
Не ноль.
Не false.
Это дырка. Выколотое значение.
тем не менее это информация
1 мар 16, 19:35    [18884289]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
daunito
Еще слишком много запросов выполняется лишних. Там где можно было передать один ID и запросом вытащить всю необходимую инфу, выполняется 30 маленьких запросов, где каждый вытаскивает кусочек информации. Например, методы getUserLastName, getUserFirstName, getUserBirthDate, getUserDocID, getDocSerialNumberById... чтобы собрать информацию о пользователе.

Я такое безумие уже видел (в приложении "Аэ..." фирмы U) - и, быть может даже, что это те же самые люди делали.

Когда-то я ругал (и до сих пор ругаю) пару фирм (H и I) за их любовь к хранимым процедурам и курсорам. Потом оказалось, что они ещё молодцы по сравнению с фирмой L с их базоданново-агностическим приложением на JBoss'е, которые на малейший чих тянут данные внутрь app-сервера и манипулируют ими там.

Но в "Аэ%" оказалось нечто особенное. К примеру, когда в Hybernate люди пытались сделать вид, будто никакой базы данных не существует и они чисто с Java работают, в "Аэ%" люди делали вид, что они работают... с диалектом Объектного Паскаля a la Delphi. Изобразили внутри базы тотальную иерархию наподобие TObject, от которого всё прямо или косвенно наследуется, каждый класс - дополнительная таблица, пара (!) пакетов на подкласс, каждое изменение - отдельный апдейт (т.е. вместа update xxx set firstname=x, lastname=y where id=z надо выполнить setfirstname и затем setlastname (после прохождения цепочки вызовов будут выполнены два update - даже Hybernate так не поступает)). Быстро такое работать в принципе не может.
7 мар 16, 15:23    [18905594]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Victor Metelitsa
Member

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


Помню я где-то читал что PG использует генетические алгоритмы для отбора наилучших планов.
Возможно это и есть так козырная карта о которой пишет т.н. "руководство".

Пусть "автор" прочитает
Cost Base Oracle Fundamentals. Jonathan Lewis
Troubleshooting Oracle Performance (second edition). Christian Antognini
а потом говорит про более умный оптимизатор PG. Проблемы такие, что скорее можно говорить про более глупых разработчиков PG. Подумать только, хинты им реализовывать западло. Вот IBM от такой глупости отказалась.
7 мар 16, 15:33    [18905626]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
mayton
Ок. Спасибо. Почитал про DB2. Насколько я понял, индексация NULL - это опция про создании
индекса. Верно?

Не совсем. DB2 NULL'ы всегда индексировала, но когда решили взять курс на попытку переманивания ораклистов, реализовали, в том числе, и возможность неиндексирования NULL'ов.

В самом деле, бывают случаи, когда выгодно NULL'ы индексировать, и бывают случая, когда выгодно, чтобы NULL'ов не было. Если выбирать одно из двух, то сложно сказать, что предпочесть. И хорошо, когда есть обе возможности.
7 мар 16, 15:42    [18905655]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5956
Victor Metelitsa
mayton
Ок. Спасибо. Почитал про DB2. Насколько я понял, индексация NULL - это опция про создании
индекса. Верно?

Не совсем. DB2 NULL'ы всегда индексировала, но когда решили взять курс на попытку переманивания ораклистов, реализовали, в том числе, и возможность неиндексирования NULL'ов.

В самом деле, бывают случаи, когда выгодно NULL'ы индексировать, и бывают случая, когда выгодно, чтобы NULL'ов не было. Если выбирать одно из двух, то сложно сказать, что предпочесть. И хорошо, когда есть обе возможности.
на самом деле корень тут в том, что оракл предпочитает вообще NULL'ы не хранить и если последние поля в конце строки(row) то их и не хранят,т.е. не занимают вообще места. Поэтому если зная это размещать опциональные nullable поля последними, то и размер базы уменьшается и нагрузка на процессор снижается.
7 мар 16, 16:20    [18905745]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54794

xtender
если зная это размещать опциональные nullable поля последними, то и размер
базы уменьшается и нагрузка на процессор снижается.

Ну да, на каждый NULL же тратится целый бит. Или всё ещё байт?..

Posted via ActualForum NNTP Server 1.5

7 мар 16, 16:28    [18905759]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5956
Dimitry Sibiryakov,

ты меня про MS SQL спрашиваешь? Не знаешь сколько там тратится?
7 мар 16, 16:29    [18905765]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5956
А вообще этот вопрос не стоит и выеденного яйца - захочешь индексировать null'ы - сможешь, оракл дает несколько возможностей. А в целом, вопрос этот чисто архитектурный и никоим образом не является минусом. Он очень схож с архитектурным подходом с EAV - хранить ли NULL в EAV и при каких условиях, т.е. заводить ли лишнюю строку в EAV-таблице если value является null: иногда выбирают что надо, иногда - нет... зависит от...
7 мар 16, 16:33    [18905780]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5956
И вообще смешно все это смешно Судя по вашим придиркам в оракле все очень и очень хорошо, если докапываетесь только до индексирования NULL'ов
7 мар 16, 16:35    [18905785]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить