Оракл...disrespect-ы

FRider

Страшное говно, а писали его сраные мудаки

FRider

Один из аргументов: Оракл считает ""(пустую строку) нуллом. Очень интересно смотеть, как код, до этого отлично работавший, начинает все время бросать NullReferenceException.

pitrik2

нефик на оракл наезжать

laki

а ты уверен что у тебя в поле записана именно пустая строка?

enochka1145

Думаю, практически все большие коммерческие проекты такие. Кроме Windows.

bastii

о, кстати, раз уж в этот тред потянутся ораклисты, такой вопрос, точнее проблемка:
на один скрипт Оракл 9 выдает сообщение об ошибке, что идентификатор слишком длинный, при этом он ссылается на идентификатор, длина которого не превышает 40 символов — как решить проблему?

FRider

Да Дениско

Ты то уж должне знатЬ, что это именно его особенность.
раз сцылга
два сцылка
Инересно, тот, кто принял такое проектное решения был вменям...

laki

бля я чето и не задумывался

и ваще я все такие запросы как правило выношу в хранимки

Helga87

Инересно, тот, кто принял такое проектное решения был вменям...

Да, но только по вторникам

laki

а ваще это реально пиздец. какое решение?

bobby

С чего ты взял, что оно имеется?

Helga87

какое решение?

Перефразируя известный анекдот про "а где же альтернатива?", решение — MS SQL Server

wwoland

А чего плохого то?

ava3443

на один скрипт Оракл 9 выдает сообщение об ошибке, что идентификатор слишком длинный, при этом он ссылается на идентификатор, длина которого не превышает 40 символов — как решить проблему?

максимум - не 40 символов, а 30.

1. Names must be from 1 to 30 bytes long with these exceptions:
* Names of databases are limited to 8 bytes.
* Names of database links can be as long as 128 bytes.

ava3443

а вообще конечно зря я отметился в этом треде, автор которого... как бы это помягче сказать... has a different background.

FRider

максимум - не 40 символов, а 30.

Кстатит да. Откуда это в 21 веке сии ограничения? как бы это помягче сказать... неособо удобные...

Names of databases are limited to 8 bytes.

про это я вообще молчу. ДОС напоминает.
Почему то МССКЛ, который так любят пообсирать ораклисты, дает более широкие возможности именования.
2Счетчик: почему плох нулл в данном случае:
1) У меня в схеме часть строковых полей помечены как недопускающие нулл. Соответственно, когда я начал грузить данные в ораклиную базу, полетели эксепшены.
2) Чтобы пофиксить проблему 1го пункта, разрешаем нуллы. Т.к. они были ранее помечены ненулевыми на уровне базы, то код, работающий с полями, не проверял их на нулльность. Опять же получаем эксепшны в отлаженном коде. Приходится его править и вставлять проверки. Вообще говоря - нулл это не очень хорошо, т.к. это частный случай из-за которого код загромождается условными операторами, что повышает его объем и ухудшает читабельность.
3)Нулл и "" - это разные всетаки концептуально вещи. Нулл - нет значения, на уровне бизнес-логики может значит, к примеру, что пользователь его не вводил. "" - значение есть, пользователь с ним работал.

pitrik2

а почему у тебя возникли эти пункты 1 и 2?
если ты собирался писать под оракл, значит ты сначала должен был изучить его особенности, а потом уже писать свой код

KViH

3)Нулл и "" - это разные всетаки концептуально вещи. Нулл - нет значения, на уровне бизнес-логики может значит, к примеру, что пользователь его не вводил. "" - значение есть, пользователь с ним работал.

Ок. Допустим пользователь редактирует поле, которое в базе будет храниться как Number. Поредактировал и все стер, сохранил. Что должно быть, концептуально, в базе? Специальный '' типа number?
Я не хочу сказать, что Null - это удобно, я к вопросу о концептуальности.

FRider

Как раз не собирался сначала. Необходимость перенести на Оракл возникла не сразу.
И насчет особенностей... я конечно понимаю, что это слабый аргумент, но и в программировании есть "общепринятые вещи", которые соблюдаются в различных системах разработки. Оракл почему то сильно выделяется, я бы сказал, не самыми интуитивными решениями.
2Бутчер: Для чисел такого естественно нет

Хотя и у чисел бывают свои "специальные" значения, отличные от нулла, например бесконечность. Но это не суть. Суть в том, что пустая строка - это вполне валидная строка, просто без символов, а нулл - это отстуствие объекта. Так в большинстве промышленных языках программирования.

pitrik2

Оракл почему то сильно выделяется, я бы сказал, не самыми интуитивными решениями.

этим все СУБД страдают
вроде стандарт SQL-92 (т.е. аж 92 года!) ни одна СУБД не соблюдает

FRider

этим все СУБД страдают
вроде стандарт SQL-92 (т.е. аж 92 года!) ни одна СУБД не соблюдает

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

ava3443

Кстатит да. Откуда это в 21 веке сии ограничения? как бы это помягче сказать... неособо удобные...

Names of databases are limited to 8 bytes.

про это я вообще молчу. ДОС напоминает.
Почему то МССКЛ, который так любят пообсирать ораклисты, дает более широкие возможности именования.

Тебе не хватает 8 символов для имени базы? Можно поинтересоваться, а сколько же у тебя ораклиных баз?

Насчёт 30 символов - упирался в это ограничение только когда автоматически генерил имена для индексов из имен полей. А для удобочитаемости больше 30 символов по-моему вредно.
P.S. MS SQL не работает на всех основных платформах кроме одной. Какая же это к чёрту СУБД?

pitrik2

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

все таки не соглашусь
во-первых интуитивно как раз понятно, что NULL это пустая строка
во-вторых про какой предыдущий опыт ты говоришь? если про опыт работы с предыдущей версией оракл, то там тоже так же было
если про опыт работы с другой СУБД, то это уже холивор: вот в опере встроен rss ридер, а в лису нет, поэтому лиса остой
если про опыт работы с другими языками программирования, т.е. не SQL, то тоже бред, SQL ничего общего с языками программирования не имеет
ты еще спроси почему в чистом HTML нету циклов, а приходится каждый раз кучу <tr><td> писать

bastii

Насчёт 30 символов - упирался в это ограничение только когда автоматически генерил имена для индексов из имен полей. А для удобочитаемости больше 30 символов по-моему вредно.

вот-вот, именно такой случай, имена для ряда атрибутов генеряться, код портируется с ms sql
можно как-то снять это ограничение?

bastii

во-первых интуитивно как раз понятно, что NULL это пустая строка

всегда казалось, что NULL принято считать как неопределенное значение, в то время как пустая строка вполне определенное значение

pitrik2

можно как-то снять это ограничение?

нельзя

FRider

во-первых интуитивно как раз понятно, что NULL это пустая строка

нет. Покажи мне хоть один язык современный, где это было бы так. Данное отличае достаточно серъезно бъет по коду, в отличае от присутствия/отстуствия рсс ридера. Категории просто разные. Ридер - это дополнительная "вкусная" фишка. Аналогию можно проводить с возможностью скажем, уведомления по емэйлу об изменениях в табличках. Нету у меня фишки - можно самому дореализовать.
А трактовка типов - это основы, на которые многое завязано. И изменить тут ничего нельзя.

если про опыт работы с другими языками программирования, т.е. не SQL, то тоже бред, SQL ничего общего с языками программирования не имеет
ты еще спроси почему в чистом HTML нету циклов, а приходится каждый раз кучу <tr><td> писать

И тут имхо ты несовсем прав, тот же PL/Sql - полноценный язык программирования.
Тут можно конечно несоглашостья, однако те СУБД, которые более интуитивны и не выбиваются из общей канвы, способны серъезно сократить время и сложность разработки

pitrik2

всегда казалось, что NULL принято считать как неопределенное значение, в то время как пустая строка вполне определенное значение

опять двадцать пять
это вам казалось с точки зрения вашего языка программирования
NULL в языке рограммирование - это несуществующая ссылка, пустая строка - это уже конкретный объект
NULL в базах данных - это отсутствие данных
пустая строка - это и есть отсутствие данных
база данных не оперирует объектами или ссылками на них, она оперирует только данными
базы данных изначально и придумывались чтобы в шкафах не хранить кучу бумаг
а на бумаге как раз так и есть: или черным по белому записаны данные (например отчество сотрудника) или не записаны, третьего не дано

FRider

всегда казалось, что NULL принято считать как неопределенное значение, в то время как пустая строка вполне определенное значение

я это уже не раз писал.

Вероятно есть разница между теми, кто привык к обычным языкам и тем кто в основном оперирует СКЛ... Т.к. поектов на "промышленных" языках подавляющее большинство, то и ориентироватся стоит на них

базы данных изначально и придумывались чтобы в шкафах не хранить кучу бумаг
а на бумаге как раз так и есть: или черным по белому записаны данные (например отчество сотрудника) или не записаны, третьего не дано

Так вот. Сейчас уже 21 век и база данных уже давно не шкаф, а умное хранилище данных, потребителем которых является программа на традиционном языке программирования. Это стоит усвоить.

bastii

NULL в базах данных - это отсутствие данных
пустая строка - это и есть отсутствие данных
база данных не оперирует объектами или ссылками на них, она оперирует только данными

причем здесь объекты и ссылки? про NULL — есть же какие-то стандарты, например, SQL-92: там как с этим?

pitrik2

причем здесь объекты и ссылки? про NULL — есть же какие-то стандарты, например, SQL-92: там как с этим?

в стандарте SQL-92 в натуре NULL и '' разные вещи
но мы вернулись к тому с чего начинали
если вы ругаете что оракл не поддерживает стандарт SQL-92, то я вам уже ответил: токо одна субд полностью поддеривает SQL-92
я так понимаю
изначально субд не создавались для языков программирования, ну или создавались но не для си-подобных языков
поэтому в оракле такую фигню и сделали
а потом поменять не захотели
в 92 году естессно уже все понимали что SQL вызываться будет в 99% случаев из программ, и там равенство null и '' будет неудобно
а оракл так и остался с досадным рудиментом

FRider

92 году естессно уже все понимали что SQL вызываться будет в 99% случаев из программ, и там равенство null и '' будет неудобно
а оракл так и остался с досадным рудиментом

вот именно

Не ждал я такого от "лучшей промышленной СУБД"

pitrik2

вот именно Не ждал я такого от "лучшей промышленной СУБД"

это еще ерунда
вот например всякие left,right join
мало того, что это в оракле появилось только в 9 версии, дык оно с кучей багов
и вроде все баги связанные с этим исправлены токо в 10 (да и то не в первом выпуске а в последующих патчах)

Dasar

NULL в базах данных - это отсутствие данных
пустая строка - это и есть отсутствие данных

имхо, фигню говоришь
вот такой код:



'1'+''+'2'

должен выдавать строку '12' на любом языке
насколько я понял, oracle в этом случае выдаст null
соотвественно более сложный пример



string a: not null

string b: not null

string c: not null



d = a + b + c;

в данном примере, в d мы должны получить нормальную конкатенацию всех строк, соответственно, если b - пустая строка ('' то должны получить просто a+c
в oracle придется делать что-то типа:



if(a is null)

  if( b is null)

    return c;

  else if (c is null)

    return b;

 else

   return b+c;

else

  if (b is null)

     if (c is null)

       return a;

    else

       return a+c;

  else if (c is null)

        return a+b;

  else

    a+b+c;

я нигде не ошибся?

wwoland

в оракл строки конкатенируются с помощью '||'
а '1'||NULL||'2' выдаст '12',
а то,что ты написал это уже численные операции и в данном контексте это,помоему, и должен быть NULL

Dasar

> а '1'||NULL||'2' выдаст '12',
т.е. Null для строк ведет себя не как NULL для других типов?

wwoland

я имел ввиду
'1'||''||'2'

KViH

а какие другие типы ты конкатенируешь? и как?

KViH

Да, и вложенные if-ы конечно писать не надо. Есть стандартные функции nvl, nvl2 - они тоже не всегда красиво выглядят, но тем не менее.

Dasar

> Да, и вложенные if-ы конечно писать не надо. Есть стандартные функции nvl, nvl2
каждый if-ы просто заменится на вызов nvl, но вложенность и большое кол-во вариантов никуда не денется.

KViH

В общем так, только пример твой не в тему. Как было уже сказано a||b выдаст нормальный результат и вложенные if-ы не нужны.

Dasar

> а какие другие типы ты конкатенируешь? и как?
так со строками я могу много чего делать, не только их конкатенировать
допустим у меня было выражение:
a || b || c
чтобы посчитать длину
выражение надо уже неочевидным образом переписать в:
notnull(length(a 0) + notnull(length(b 0) + notnull(length(c 0)
найти хвост
tail = substring(s, 0, length(prefix
tail = if prefix is null return s else return substring(s, 0, length(prefix
т.е. получается что любое сложное выражение, которое работает со строками необходимо обрамлять в большую последовательность if-ов.

KViH

Не совсем я понял написанное. Но по-моему nvl(length(a||b||c0) должно помочь. Т.е. пример не в тему.

Helga87

У тебя происходит конкатенация строк. А для того, чтобы посчитать длину, обычно хочется просто сложить несколько чисел. Разница в производительности будет огромной, особенно если строки не состоят из нескольких букв.

Dasar

> Не совсем я понял написанное. Но по-моему nvl(length(a||b||c0) должно помочь. Т.е. пример не в тему.
конечно поможет, любое выражение можно записать на любом алгоритмически полном языке.
только почему-то все предпочитают писать выражения не на машине тьюринга....
цель хорошего языка программирования - это уменьшить кол-во рассматриваемых вариантов и уменьшить длину записи выражений
обсуждаемое правило поведение oracle-а, наоборот, увеличивает кол-во рассматриваемых вариантов и увеличивает длину записи выражений
ps
> Но по-моему nvl(length(a||b||c0) должно помочь.
так такой переход надо специально делать.
было выражение a||b||c
дальше надо посчитать длину получаем
lenA + lenB + lenC
дальше
lenA + notnull(length(b 0) + lenC
lenA + notnull(length(b 0) + notnull(length(c 0)
т.е. приходится простые переходы (простые рефакторинги) заменять на сложные, в которых приходится анализировать неочевидное поведение выражения

Marinavo_0507

обсуждаемое правило поведение oracle-а, наоборот, увеличивает кол-во рассматриваемых вариантов и увеличивает длину записи выражений

А чего ты ожидал от таких устаревших технологий, как РСУБД и SQL?

У всех реализаций какие-нибудь древние косяки, да есть.

KViH

to : Да я и не говорил, что nvl(..) и ''=null - шибко удобно. Но это мелкая неприятная деталь. А наличие многовложенных if-ов - это все-таки больше особенность программиста, а не языка.
to : Да не вопрос. Только бдеть о производительности нужно гораздо реже чем не бдеть

to : уже есть адекватная замена этим вещам?

Marinavo_0507

to : уже есть адекватная замена этим вещам?

адекватная чему?
в смысле buzzword compliance - есть xml native базы

Helga87

to : Да не вопрос. Только бдеть о производительности нужно гораздо реже чем не бдеть

Пусть у нас строки длиной в сто символов, а операция вычисления суммы строк частая. Это значит, что твой метод будет в сто раз медленнее, чем мог бы быть. Из, значит, для обеспечения той же производительности надо будет покупать сервер в 100 раз быстрее (и в 1000 раз дороже). Это круто?

KViH

Твои умозрительные построения от лукавого. И руководствоваться ими при написании кода не стоит. Будут проблемы с производительностью, найдешь узкие места, поправишь код в этих местах. А делать это априори не стоит.

Helga87

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

KViH

применимо к содержательной части приложения, которая может очень сильно меняться за время разработки и,

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

Helga87

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

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

KViH

Ну типа, вариант 1:

declare

    v_Length number;

begin

    dbms_output.put_line(to_char(sysdate, 'MI:SS';

    for idx in 1..9000000 

    loop

        v_Length := length('прусь' || 'от квашенных ' || 'сисек');

     --   v_Length := length('прусь')+length('от квашенных ')+length('сисек');

    end loop;

    dbms_output.put_line(to_char(sysdate, 'MI:SS';    

end;

время: ~11сек.
Вариант 2:

declare

    v_Length number;

begin

    dbms_output.put_line(to_char(sysdate, 'MI:SS';

    for idx in 1..9000000 

    loop

     --   v_Length := length('прусь' || 'от квашенных ' || 'сисек');

        v_Length := length('прусь')+length('от квашенных ')+length('сисек');

    end loop;

    dbms_output.put_line(to_char(sysdate, 'MI:SS';    

end;

время: ~ 16сек.
или не то имелось ввиду?

pitrik2

вот такой код: '1'+''+'2'
должен выдавать строку '12' на любом языке
насколько я понял, oracle в этом случае выдаст null

нет
ты понял неправильно
во-первых, сложить строки нельзя, их можно только конкатенировать
конкатенация налла - тоесть конкатенация пустого места - это вполне адекватная операция и налл она никак не вернет
во-вторых
правило точно звучит так
1) пустая строка типа VARCHAR является NULL
2) '' не является NULL
более подробно тут

ava3443

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

a10063

скорее всего, оракловский компилятор должен иметь в запасе базовый оптимизатор (точно не знаю, но это было бы разумно)
соответственно, в первом примере на этапе исполнения строка v_Length := length('прусь' || 'от квашенных ' || 'сисек'); будет выполняться как v_Length := length('прусьот квашенных сисек');
вообще, не понятно, почему обе программы не выполняются 0 сек., ведь v_Length потом нигде не используется... видимо, оптимизатор совсем слаб...

Helga87

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

Ситуацию у автора темы другая. Была программа, которая отлично работала с ms sql. Затем потребовалась поддержка и Oracle-овой базы. При миграции на Oracle неожиданно (да, здесь автор темы не знал о том, что такая фигня) выяснилось, что пустая строка и null — это одно и то же. Заранее этого спрогнозировать было нельзя, т.к. и в стандарте и в ряде других БД такого нет. Вывод: портировать на Oracle дороже, чем хотелось бы. Недовольство именно этим пунктом и высказал автор темы.

Marinavo_0507

видимо, оптимизатор совсем слаб...

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

0000

> При миграции на Oracle неожиданно
О сколько нам мгновений чудных
Готовит просвещенья дух
И опыт, сын ошибок трудных,
И гений пародоксов друг.
А.С Пушкин

a10063

а кто будет оптимизировать устаревшие технологии, если можно продвигать новые?

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

Marinavo_0507

> но на рынке oracle уже не первый год...
дык уже не первый год новизна важнее эффективности
по сравнению с явой pl/sql - чудо-эффективная штука

FRider

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

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

0000

Том Кайт

при создании приложений базы данных самым важным компонентом программного обеспечения является СУБД.
...
Странная идея о том, что разработчик приложения баз данных должен быть огражден от СУБД, чрезвычайно живуча. Многие почему-то считают, что разработчикам не следует тратить время на изучение СУБД.
...
Это не критика инструментальных средств или современных технологий, таких как компоненты EJB и поддержка постоянного существования на базе контейнеров. Это — критика намеренного игнорирования особенностей СУБД, принципов ее работы и использования.

Все СУБД различны и нельзя их считать аналогичными.

FRider

Все СУБД различны и нельзя их считать аналогичными.

это нормально?

при создании приложений базы данных самым важным компонентом программного обеспечения является СУБД

Это КРАЙНЕ спорное утверждение и с ним еще как можно не соглашаться.

pitrik2

это нормально?

да
вполне
если бы все СУБД были одинаковыми, то и выбора бы не было
а стандарты никто не держит никогда, так что это вощемто тоже нормально
например, html&css
ИЕ нифига стандарты не держит, но при этом 80% пользователей инета выбрали ИЕ

Andr163

>ИЕ нифига стандарты не держит, но при этом 80% пользователей инета выбрали ИЕ
жесть

ava3443

Это КРАЙНЕ спорное утверждение и с ним еще как можно не соглашаться.

А что важнее? Application Server? Сравни стоимость лицензий на СУБД и на апп-серверы и сразу станет ясно, что тут более важно, а что - менее.

0000

> при создании приложений базы данных самым важным компонентом программного обеспечения является СУБД
Это КРАЙНЕ спорное утверждение и с ним еще как можно не соглашаться.

Если ты хочешь чтобы твой апп-сервер работал на нескольких БД, то тут ты жертвуешь очень сильно производительностью - потому как идеология разная - то что будет быстро в MS SQL Server возможно будет очень медленно в Oracle по ряду причин. Вообщем если б ты не поленился Том Кайта почитать, то думаю бы согласился с ним - он достаточно хорошие аргументы привел.
Ксати есть такая шарага в Москве Bank's Soft System (BSS). Одно из направлений у них - по для муниципала - для казначейств в частности. Так вот, там есть такой сервер приложения, который может работать как на SyBase, так и на Oracle. Как он работает рассказать?

Ilya1974

Покажи мне хоть один язык современный, где это было бы так

ska:~ gleb$ perl -e 'print "" == NULL'

1

bansek

Проблема не только в портирование.
меня угнетает вот такая ситуация:
сначала я делаю
INSERT INTO tbl (str) VALUES (?)
pstmt.setString(1, str);
а потом делаю так:
SELECT * FROM tbl WHERE str = ?
pstmt.setString(1, str);
так вот, если str не дай Бог пустая, то ничего у меня не выйдет.
Что прямо скажем, неколько обескураживает - вот же я эту запись в БД клал строчкой выще, а теперь ее найти не могу ...

Marinavo_0507

Распространение заведомо ложной информации для незнающих perl. Незачот без права пересдачи.

Оставить комментарий