Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Containing c параметрами - нельзя ли сравнить?  [new]
Интересующийся ТС
Guest
В FireBird, чтобы запрос

select * from Some_Table
  where :param containing 'Строка символов' (или_поле_таблички)

выполнился, нужно, бы во время выполнения значение параметра :param было не длиннее, чем 'Строка символов' (или не длиннее соотв. поля таблички Some_Table).
Иначе сервер выброси исключение: https://www.sql.ru/forum/actualthread.aspx?tid=822992

Предлагается заранее выполнить Cast для определения нужного размера (с "запасом").

select * from Some_Table
  where Cast(:param as varchar (1024)) containing 'Строка символов' (или_поле_таблички)

Интересно - у "взрослых" СУБД, типа Оракл или МС СКЛ - точно так же, нужно явно определять размер?
25 янв 11, 00:11    [10124359]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
Dimitry Sibiryakov
Member

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

Интересующийся ТС
Интересно - у "взрослых" СУБД, типа Оракл или МС СКЛ - точно так же, нужно явно определять
размер?

Вопрос не имеет смысла - у "взрослых СУБД" вообще нет оператора CONTAINING.

Posted via ActualForum NNTP Server 1.4

25 янв 11, 00:47    [10124487]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
Интересующийся ТС
Интересно - у "взрослых" СУБД, типа Оракл или МС СКЛ - точно так же, нужно явно определять размер?

У FB хватает странных ограничений, например буквально вчера он у меня отказался создать индекс по varchar(300). На 2.1 работал, а на 2.0 ниасилил.

Про МС не скажу, а в Оракле довольно трудно придумать, когда бы требовалось указать cast с размером. Он и без размера-то употребляется редко, в основном для подстановки в запрос выборок из табличных функций.
25 янв 11, 09:52    [10125086]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
Dimitry Sibiryakov
Member

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

softwarer
буквально вчера он у меня отказался создать индекс по varchar(300). На 2.1 работал, а на
2.0 ниасилил.

С теми, кто не ниасилил документацию, случаются и не такие неприятности...

Posted via ActualForum NNTP Server 1.4

25 янв 11, 11:05    [10125671]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
Dimitry Sibiryakov
С теми, кто не ниасилил документацию, случаются и не такие неприятности...

Ага. Видать, где-то в сети лежит такая волшебная документация, что от её асиливания лимиты чудесным образом раздвигаются
25 янв 11, 11:13    [10125760]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
softwarer,

в 2.0 размер страницы 1К небось? Сам додумался или кто другой тебе жизнь испортил? ;-)
25 янв 11, 11:23    [10125855]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
dimitr
в 2.0 размер страницы 1К небось?

Представления не имею - это не моя база, пользователи скрипта пожаловались на ошибки. Впрочем, в 2.1 та же база, создававшаяся по идее теми же скриптами (просто файл, который я когда-то скопировал к себе, представления не имею, какой версией FB он поддерживался до копирования). Так что либо размер страницы одинаковый, либо дефолтовый.
25 янв 11, 11:30    [10125922]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
softwarer,

в скрипте запросто может быть жестко прошит размер страницы в 1К в CREATE DATABASE. Версии до 2.1 это поддерживали, а 2.1 втихую апгрейдит его до 4К, т.к. меньше не поддерживает. Отсюда и разница на индексах. В оракле ведь тоже макс. размер ключа зависит от размера блока.
25 янв 11, 11:36    [10125971]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
dimitr
а 2.1 втихую апгрейдит его до 4К, т.к. меньше не поддерживает.

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

dimitr
В оракле ведь тоже макс. размер ключа зависит от размера блока.

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

Если обратите внимание, я не против ограничений, но отметил, что в FB они порой довольно странные и неожиданные (с точки зрения моей версии здравого смысла). В данном случае мой здравый смысл говорит, что создание индекса по двум memo-полям - ситуация крайне редкая и бессмысленная, то есть ограничение практически роли не играет. Создание индекса по одному бизнес-полю (ограничение длины взято на основе данных государственного справочника + запас) - ситуация достаточно частая, и невозможность это сделать - для меня была неожиданна.
25 янв 11, 11:50    [10126142]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
softwarer
Хм. На месте FB-разработчика я бы высказался на тему такой самостоятельности. Имхо, если инструмент не может выполнить прямую и недвусмысленную команду, он должен выдать ошибку, а не тихой сапой "делать что могу".

а чем страница 4К хуже для разработчика, чем 1К? Все как работало, так и будет. Только заметно быстрее, уж поверьте. Ну и "непонятные" лимиты не будут портить жизнь ;-) А вот ваше предложение обрубит туеву хучу скриптов, в которых тупые разработчики в эпоху царя гороха беспричинно заложились на размер 1К. Бекапы перестанут переноситься на новую версию, и т.п. геморрой.

softwarer
Зависит. Только большинство разработчиков ни разу в жизни на это ограничение не натыкаются, поскольку оно чаще всего порядка 6500 байт в то время как varchar ограничен 4000 байт.

6.5К оно на дефолтном (и заодно минимальном?) блоке 8К. Если бы оракл поддерживал размер блока в 1К, то лимит был бы порядка 700 байт и вы бы наверняка наткнулись на него при индексации очередного "бизнес-поля" лишь чуток длиннее, чем сейчас. Был бы тот же уровень неожиданности.

как видим, никакой фантастики тут нет. Есть лишь большее дефолтное удобство оракла в данном случае. И увеличение нижнего предела в ФБ 2.1 служит той же цели.
25 янв 11, 12:05    [10126331]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
dimitr
а чем страница 4К хуже для разработчика, чем 1К? Все как работало, так и будет.

До тех пор, пока "всё" соответствует ожиданиям разработчиков СУБД. Но всегда найдётся какой-нибудь вывернутый функционал, который из-за этого начнёт глючить. Для FB я вряд ли приведу разумный пример, с бедра - if page_count * 1024 * 0.9 > file_limit then print "Пора заводить новую базу". Скажем, в Oracle мне помнится подобное, когда была создана таблица с извратными параметрами вроде initial 8K next 80K pctincrease 1000 maxextents 10, а потом вышел девятый оракл, и этот скрипт натравили на uniform size табличное пространство - внедрились, всё чудесно, и вдруг система рухнула по максимальному объёму таблицы.

dimitr
в которых тупые разработчики в эпоху царя гороха беспричинно заложились на размер 1К.

А если умные и причинно? :) Это вечный вопрос.. по мне, лучше исправить падающий скрипт в явном и очевидном месте, нежели отлавливать тонкие проблемы хрен знает где только потому, что СУБД считает себя умнее разработчика.

dimitr
6.5К оно на дефолтном (и заодно минимальном?) блоке 8К. Если бы оракл поддерживал размер блока в 1К,

То либо индекс допускал бы превышение размера блока, либо я ругался бы на индексы и в оракле тоже :) Де-факто же в оракле есть пожалуй что два дурных ограничения: 30 байт на размер идентификатора и 1000 значений внутри in(...) списка. Во всяком случае это что вспомнилось сходу.

Теоретически минимальный блок 4К. Практически поддержка в одном экземпляре табличных пространств с разным размером блока - геморрой очччень сомнительной полезности, поэтому подавляющее большинство экземпляров работают с 8К блоками, небольшое количество - с 16К.

dimitr
как видим, никакой фантастики тут нет.

А магии вообще не существует. "Со стороны разработчика продукта" я понимаю наличие ограничений. "Со стороны потребителя продукта" я полагаю, что ограничения должны соответствовать потребностям пользователя. Соответственно, со своей стороны - стороны проектировщика - я склонен говорить разработчику "вот это надо обеспечить, а как это сделать - если не знаешь, давай думать вместе".
25 янв 11, 12:33    [10126604]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
softwarer
До тех пор, пока "всё" соответствует ожиданиям разработчиков СУБД. Но всегда найдётся какой-нибудь вывернутый функционал, который из-за этого начнёт глючить.

значит, он этого заслуживает :-) К слову, со времени выпуска 2.1 ни одного такого случая анналы не зафиксировали.

softwarer
А если умные и причинно? :)

это фантастика :-)

softwarer
по мне, лучше исправить падающий скрипт в явном и очевидном месте, нежели отлавливать тонкие проблемы хрен знает где только потому, что СУБД считает себя умнее разработчика

если бы все были такими, моя жизнь вероятно стала бы намного проще :-)

softwarer
То либо индекс допускал бы превышение размера блока

есть хоть одна СУБД, поддерживающая такое? Теория и практика тут несколько конфликтуют.

softwarer
Де-факто же в оракле есть пожалуй что два дурных ограничения: 30 байт на размер идентификатора и 1000 значений внутри in(...) списка

оба есть и в ФБ, если это утешит :-) Есть и другие, конечно. Хотя с точки зрения ФБ-шника оракловое ограничение на размер строки в 4К тоже абсолютно дурное.
25 янв 11, 13:39    [10127118]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
Dimitry Sibiryakov
Member

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

softwarer
В данном случае мой здравый смысл говорит, что создание индекса по двум memo-полям -
ситуация крайне редкая и бессмысленная

В основном ещё и тем, что memo это BLOB, а они индексированию не поддаются вообще.

dimitr
оба есть и в ФБ, если это утешит :-)

Не утешит, поскольку в ФБ они больше: 32 символа и 1500 значений в in.

И если уж речь зашла о дурацких ограничениях, меня немало удивила невозможность в Оракуле
предсказать сколько максимально байт может занять на клиенте значение из поля NCHAR. Как
они не натыкаются на BOF - совершенно непонятно.

Posted via ActualForum NNTP Server 1.4

25 янв 11, 13:57    [10127281]     Ответить | Цитировать Сообщить модератору
 Re: Containing c параметрами - нельзя ли сравнить?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
dimitr
если бы все были такими, моя жизнь вероятно стала бы намного проще :-)

Дык все таковы, какими Вы их видите/формируете.

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

dimitr
оба есть и в ФБ, если это утешит :-)

Да нет, не утешит. Имхо со времён минимум Oracle 8, когда оно начало конкретно мешать, можно было бы хотя бы поднять до varchar(300), если уж не придумать чего попродвинутее. А с IN() и вовсе - стандартный обход через IN(..) OR IN(..) OR IN(..) показывает сугубую искусственность, неразумность ограничения.

dimitr
Хотя с точки зрения ФБ-шника оракловое ограничение на размер строки в 4К тоже абсолютно дурное.

Я не очень понимаю слова "с точки зрения ФБ-шника". От них тянет флеймом. Имхо в данном случае есть точка зрения абстрактного БД-разработчика с реальными прикладными задачами. И с их точки зрения, имхо, ограничение размера строки в, допустим, 40 символов было бы невменяемым, в 200 - неудобным, а начиная, например, от 1000 где стоит граница - там и ладно, всё равно она где-то должна стоять. Я знаю случай, когда не хватило и ораклового ограничения на размер строки в 32К, но тут вопрос простой - либо оно есть, либо его (реального) нет. Второе пока делать не любят, хотя имхо это вопрос больше замшелого наследия, нежели реальной сложности.
25 янв 11, 13:58    [10127295]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить