Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 13 14 [15] 16 17   вперед  Ctrl
 Re: Все таки Oracle впереди планеты всей!  [new]
Sgt.Pepper
Member

Откуда: spb
Сообщений: 1166
vadiminfo
Уточните плиз эти аксиомы, что из них стоящего вывели, чтобы оценить пользу, ну и применть. Я пока не в курсах и считаю NULL вынужденным злом, потому что неопределенности мне не нужны в БД, ввиду их возможности озадачить потребителя информации, и даже сбить с толку в некоторых случаях.

Внешний джойн всегда в общем случае, порождает null'ы, в этих неопределенностях есть много определенно логичного и совершенно однозначно интерпретируемого, в нем столько же зла, сколько и в пустом множестве (коим можно обозвать пустую строку), и в 38.8 по цельсию на градуснике, и в кляксе на библии. Можно ли конкатенцию символов "Ё" и "б" считать ЗЛОМ, или классификатором документа, в котором она встречается, и исходной информацией для применения соответствующих алгоритмов?
:)
15 июл 10, 01:24    [9106405]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
ЛП
Guest
Sgt.Pepper
Внешний джойн всегда в общем случае, порождает null'ы, в этих неопределенностях

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

Однако ж все продолжают путать.
Чего уж тут ожидать от бедных школьников, заблудившихся среди бэдэшных нуллов и неинициализированных объектных ссылок в каком-то языке программирования.

Это так, к слову пришлось :)
15 июл 10, 04:46    [9106531]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
web_fox
По правильному любые операции с NULL должны приводить к исключению.
Я верно понял вашу мысль о том, что все СУБД работают совершенно неправильно? Или вы можете назвать СУБД, которая при конкатенации с null выдает исключение?
А если все СУБД работают неправильно, то вопрос лишь в том, какая из "неправильностей" удобнее, привычнее и т.п.
15 июл 10, 08:48    [9106763]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Favn
vadiminfo
В тексте нет главного(ных) утверждений ради которых все эти рассуждения. Они видимо предпролагаются. Но судя по тексту у меня сомнения на это счет имеются.
Это утверждение было в предыдущих постах. Пожалуйста, повторю точнее:
NULL в SQL введен как обозначение неопределенного в данный момент значения.

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

NULL - в SQL выглядит как "не заполненое" без уточнеия почему: то ли значение есть но не известно, толи свойство отсутсвует (ну действительно, это буквальное звучание NULL). В этом смысле NULL и привносит неопределенность в МД. Это как бы можно только в коментаритях пометить, а так в МД не отличить.
А у Вас тока свойство есть, но значение не известно. У Вас определенность, но не понятно что использовать для "обозначения" свойство отсутсвует. У меня понятнго что, но не определенность.

То что NULL не может быть испотльзован как свойство отсутсвует не следует из
Favn

Это следует из получения NULL как результата любой логической операции с операндом NULL в любой РСУБД.
.

Вообщето "как результат любой логической операции с операндом NULL " получается UNRNOWN, а не NULL. Здесь важно, что отрицание UNRNOWN снова UNRNOWN, что позволяет в принцие подходит и к свойство отсутсвует. Т.е. в условиях отбора, если он появится, то запрос поведет себя предсказуемым образом для трезначной логики.

По этому
Favn

И аналогично NULL является результатом вообще любой операции с операндом NULL в вообще любой РСУБД (кроме, конечно, проверок на NULL).
.

вовсе не аналогично. Это другие операции. Они уже менее могут подходить к обоим вариантам.
Но это значит что синтаксис не подходит к модели. Посто его приходится не применять: NULL в голом виде не испотльзовать.

Т.е. я думаю, что выход в добавлении кроме NULL еще чего-то, чтобы можно было "обозначить" оба варианта.

Favn

Единственное исключение - это именно строковые типы именно в Оракле. Что со стороны Оракла кажется мне нелогичным и ошибочным.

Переход с NULL на пустые строки Вы сделали без уточнения в какой связи: что из чего тут следует Вы на этот раз не указали.
Пустая строка, например в акцессе как логическая операция возвращает либо FALSE либо TRUE, но не UNRNOWN. В Оракле наверное UNRNOWN, но ее наличие в таблах БД проверить удается в отличии от NULL. Лично для меня от этого только польза: семантичность пустой строки в МД мне не ясна,
а контролировать ее приходится. Речь идет об МД, а процедурном программировангии она нужна в связи с вычислениями.

Favn


Рассуждения о философском смысле числа 0 и индоевропейских языках предлагаю отставить в сторону. Возможно, я увлекся. Но и не только я. ;)

Ну там было про недостаточную определенность термина "неопределенность".


Favn

В любом случае - понятия NULL в смысле "значение не определено" нет в явном виде ни в арифметике, ни в операциях над строками в программировании на большинстве универсальных языков.
Это понятие есть в SQL с его процедурными расширениями.

Ну вот видите? Поэтому и привлекать рассуждения про арифметику в обоснование утверждения про NULL, возможно, преждевременно.


Favn

А вот "пустая строка" есть практически везде, и отнюдь не в смысле "значение не определено", а в смысле "строка, не содержащая символов, т.е. пустая".

Наверняка мы можем знать, что тока в прогах пустые строки есть. Где ими еще занисмаются в отличии от чисел? Ну в терии информации может, ну и то наверное опять в связи с алгоритмами. Т.е. "практически везде" в компах. И то не везде.

Favn


Кроме Оракла, конечно. Т.е. тут ('' в смысле "значение не определено") Оракл выбивается не только из ряда РСУБД, но и из ряда практически всех остальных систем программирования, что выглядит по меньшей мере странно.

Так Оракле в таблах пустых строк не найти, потому ни в каком значении в МД пустым строкам места, вроде, нет. Это в Аксцессе я када-то пробовал именно, чтобы иметь все случаи: NULL значение есть но не известно, а пустая значение отсутсвует. Но отказался (отсутсвовать могут значения и не строковх типов, а логические опреции с истина или ложь тоже не подошли).


Favn

При чем тут теория множеств?

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

Favn

Мы рассматриваем NULL в контексте РСУБД. Для них не надо расширять множества и определять операции - все давно определено стандартом, а вовсе не мной.

Вот и я гАвАрУ. Потому все еще скептически отношусь к попыткам строго вывести про то, что должна операция и про арифметику и проч.
15 июл 10, 09:32    [9106999]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Sgt.Pepper
vadiminfo
Уточните плиз эти аксиомы, что из них стоящего вывели, чтобы оценить пользу, ну и применть. Я пока не в курсах и считаю NULL вынужденным злом, потому что неопределенности мне не нужны в БД, ввиду их возможности озадачить потребителя информации, и даже сбить с толку в некоторых случаях.

Внешний джойн всегда в общем случае, порождает null'ы, в этих неопределенностях есть много определенно логичного и совершенно однозначно интерпретируемого, в нем столько же зла, сколько и в пустом множестве (коим можно обозвать пустую строку), и в 38.8 по цельсию на градуснике, и в кляксе на библии. Можно ли конкатенцию символов "Ё" и "б" считать ЗЛОМ, или классификатором документа, в котором она встречается, и исходной информацией для применения соответствующих алгоритмов?
:)

Ну про что там за аксиомы не понял.
Что до NULL в джойнах и зла, так в этих внешних джойнах разве нет, как правило, еще отделения зла, либо выяснения на скока много "зла"? Часто для внешние сединения приходится писать, чтобы зло не прокаралось. Да и как же это интерпретируется? Более часто как свойство отсутсвует или чаще как не известно. И аксимы какие тут применишь?
15 июл 10, 10:29    [9107504]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
является. там обычный жава код с декларативными embedded SQL вставками для препроцесора. убери вставки и останется pure java.
Правильно. И соответствующий стандарту препроцессор занимается именно тем, что преобразует стандартные директивы SQLJ в вызовы некоего (зависящего от СУБД) API, после чего текст м.б. откомпилячен стандартным компилером, т.е. "убирает вставки и останется pure java". Именно это я и утверждал.
Yo.!
вот оракловое определение: "A SQLJ program is a Java program containing embedded SQL statements that comply with the International Standardization Organization (ISO) standard SQLJ Language Reference syntax."
И тут все правильно. В стандарте есть синтаксис SQLJ, но нигде не сказано, что компилер должен его жрать без предобработки. Попробуйте скормить SQLJ напрямую сановскому компилеру, в конце концов.
Yo.!
да, впечатляет. куда там оракловому syntax shugar написанному с нуля и являющемся частью ядра
Э... Был бы весьма признателен за ссылку на тот чудесный факт, что именно SQLJ является частью именно ядра Оракла. Мы обсуждали это в прошлом году, и мне попадались ссылки на то, что:
1. SQLJ (статика) в Оракле преобразуется в вызовы JDBC (динамика), т.е. является именно syntax shugar.
2. JVM в Оракл является внешней по отн. к SQL процессору (как и PL/SQL VM), но управляется ядром. При этом имеет свою область памяти, настраиваемую отдельными параметрами.
3. Да, ядро запускает в ней сборщик мусора, что, видимо, и является теснейшей интеграцией ;)
4. Да, JVM копирует данные в/из переменных Java в структуры ядра. Но то же самое делает и type 2 драйвер в DB2.
Возможно, тогда я что-то пропустил или появилась нова информация.
Yo.!
ЗЫ. теперь надеюсь ясно "Какой-такой декларативный SQL в Java процедуре?"
И теперь, и тогда мне совершенно ясно, что любой SQL является декларативным (языком программирования). В отличие от процедурных :)
А в тексте программы SQL может быть статическим (прямо в тексте написанным) или динамическим (выполняемом из строковых переменных).
И мне до сих пор интересно, выполняется ли для SQLJ, т.е. статического SQL, валидация с изменениями схемы БД в Оракле. Из-за трансляции в JDBC у меня есть сомнения на этот счет.
15 июл 10, 12:24    [9108555]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Favn
Member

Откуда:
Сообщений: 585
web_fox
О боги! Откуда вы это всё придумали??? Из MMX-инструкций, устройства FPU?
Какое ещё множество какой такой неопределённостью расширить?
По правильному любые операции с NULL должны приводить к исключению. Если ваша программа дошла до умножения или сложения чего-то с тем, чего не существует - это ошибка при реализации бизнес-логики, это как в сях записать что-то в память по неинициализированному указателю, просто ошибка.
Мда. Еще один. "Дорогая, их тут тысячи!" (с)
NULL в процедурных языках с C-подобным синтаксисом не имеет никакого отношения к NULL в SQL. В первых - это пустой указатель (ссылка в Java и т.п.), во втором - unknown, неизвестное (неопределенное) значение.
Различить их очень просто - по операции сравнения.
Сравнение переменной с NULL в процедурных языках дает true или false в зависимости от содержимого переменной. Т.е. NULL является вполне определенным (пустым) значением.
Сравнение с NULL в SQL там, где есть тип boolean, даст тоже NULL вне зависимости от значения сравниваемого поля. И в любой СУБД не даст ни true, ни false. То есть значение unknown, не определено, и любая операция с ним (кроме проверки на NULL) естественно приведет к unknown результату.
Из логики с NULL следует, что у этих языков разные первичные определения NULL, т.е. аксиоматика.
web_fox
NULL - это просто флаг(!), который говорит, что значения нет. Как я уже сказал, фактически это отдельное(!) свойство, а не отдельное значение. Это, если хотите, атавизм синтаксиса современного SQL, потому что синтаксически присваивается по значению как обычное значение, хотя реально является отдельным самостоятельным свойством, например: !Apple.isNull() ? Apple.GetColor() : RaiseException().
При чем тут флаг? Опять путаете смысл NULL в SQL и его интерпретацию в прикладных библиотеках конкретного языка, в синтаксисе которого возможность unknown значений отсутствует.
15 июл 10, 12:43    [9108768]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Favn
Member

Откуда:
Сообщений: 585
vadiminfo
Наверное, стоит Ваше утверждение усилить словом "только": "только для обозначения неопределенного в данный момент значения", поскольку я, например, думаю что не только для этого его приходится использовать. Ну действительно, а что введено в SQL для "обозначения" свойство отсутсвует - не определено не тока в данный, но и во все последующие моменты? Значение даже специальное в этом случае искажение (значения нет).
Если бы я хотел усилить свое утверждение, я бы и сам с эти справился :)
Как правильно написал ЛП, null может означать и отсутствие значения (как результат внешнего объединения), но это выходит за рамки обсуждаемой "фичи" Оракла. В полях же БД он изначально означает именно unknown, т.е. неизвестно, не определено. Это следует из логических операций над ним. Сравнение любого определенного значения с "пусто" должно возвращать определенный ответ true/false, а вовсе не "unknown", как сравнение с null.
Тем не менее, проектировщик БД вправе использовать его как маркер особого значения, например пустого. Что я лично считаю плохим тоном, т.к. это противоречит той же логике.
vadiminfo
NULL - в SQL выглядит как "не заполненое" без уточнеия почему: то ли значение есть но не известно, толи свойство отсутсвует (ну действительно, это буквальное звучание NULL). В этом смысле NULL и привносит неопределенность в МД. Это как бы можно только в коментаритях пометить, а так в МД не отличить.
Его можно использовать как "свойство отсутствует". Как и любое другое значение, написав default '' например. Просто default null принимается по-умолчанию, и все.
vadiminfo
А у Вас тока свойство есть, но значение не известно. У Вас определенность, но не понятно что использовать для "обозначения" свойство отсутсвует. У меня понятнго что, но не определенность.
Прошу прощения, но фразу не понял. "Кто на ком стоял?" (с)
vadiminfo
Вообщето "как результат любой логической операции с операндом NULL " получается UNRNOWN, а не NULL.
Вообще-то, в трехзначной логике NULL и означает UNKNOWN. Просто в классическом SQL нет типа boolean. Цитата о типе boolean из DB2:
"Boolean value represents a truth value of TRUE or FALSE. A Boolean expression or predicate can result in a value of unknown, which is represented as the null value."
Т.е. в IBM считают, что булевский unknown есть null. Думаю, что в Оракле - тоже, раз в DB2 его ввели недавно для совместимости с ним. Я склонен согласиться с ними обоими :)
vadiminfo
Здесь важно, что отрицание UNRNOWN снова UNRNOWN, что позволяет в принцие подходит и к свойство отсутсвует. Т.е. в условиях отбора, если он появится, то запрос поведет себя предсказуемым образом для трезначной логики.
Как раз к "отсутствует" логика с NULL не подходит, т.к. результат равенства/неравенства с "отсутствует" вполне определен - либо значение там есть, либо его там нет :)
vadiminfo
вовсе не аналогично. Это другие операции. Они уже менее могут подходить к обоим вариантам. Но это значит что синтаксис не подходит к модели. Посто его приходится не применять: NULL в голом виде не использовать.
Т.е. я думаю, что выход в добавлении кроме NULL еще чего-то, чтобы можно было "обозначить" оба варианта.
Я придерживаюсь другого подхода - применяю NULL именно в значении "unknown", неизвестно. И синтаксис с логикой тогда подходят, и с моделями - никаких несоответствий.
А значение "пусто" можно обозначить любым подходящим из множества значений поля, например '' для строк написав default ''.
vadiminfo
Переход с NULL на пустые строки Вы сделали без уточнения в какой связи: что из чего тут следует Вы на этот раз не указали.
Пустая строка, например в акцессе как логическая операция возвращает либо FALSE либо TRUE, но не UNRNOWN. В Оракле наверное UNRNOWN, но ее наличие в таблах БД проверить удается в отличии от NULL. Лично для меня от этого только польза: семантичность пустой строки в МД мне не ясна, а контролировать ее приходится. Речь идет об МД, а процедурном программировангии она нужна в связи с вычислениями.
Связь простая - раз в общем случае NULL может означать "unknown", конкатенация с ним по логике тоже должна вернуть "unknown", т.е. NULL. Т.к. результат остается неизвестным. А в Оракл, по факту результата операций, null/'' означает unknown в операциях сравнения и пустую строку - в конкатенации. В чем и противоречие.
Семантичность пустой строки полностью зависит от внешнего отн. БД приложения и может означать именно "пустое, определенно пустое значение", например. Да это в контексте разговора о СУБД и не важно, как и значение '' в процедурном программировании. Просто литерал '' есть в SQL, и означает он именно пустую строку, и ничего больше. В любом SQL, за одним исключением :)
vadiminfo
Ну вот видите? Поэтому и привлекать рассуждения про арифметику в обоснование утверждения про NULL, возможно, преждевременно.
В арифметике нет NULL. Но в SQL есть арифметика. Именно в контексте ее использования в SQL я ее и "привлекал". Ну, разве что с делением увлекся :) Хотя арифметику к этому обсуждению приплетали и до меня, можно считать это ответом.
vadiminfo
Наверняка мы можем знать, что тока в прогах пустые строки есть. Где ими еще занисмаются в отличии от чисел? Ну в терии информации может, ну и то наверное опять в связи с алгоритмами. Т.е. "практически везде" в компах. И то не везде.
Минуточку, не надо выдергивать из контекста. Я писал только о пустых строках в ЯП вообще и в SQL в частности. "Обобщенная роль пустых строк в мироздании" меня никогда не интересовала.
vadiminfo
При том, что Вы пытались говорить о том что должна операция с операндами NULL. А множества хорошо показали себя када думают что же должна операция. Так как если на ея смотреть как на отображение множеств, то картина более цельная может получиться.
Отн. varchar в Оракле у меня цельной картины не получается. А именно - в операциях сравнения null ведет себя именно как "unknown", а вовсе не как определенное значение '', входящее в множество возможных значений поля varchar. В строковых же операциях он же ведет себя именно как вполне определенный '', иначе результат был бы тоже NULL. В чем я и вижу противоречие.
vadiminfo
Вот и я гАвАрУ. Потому все еще скептически отношусь к попыткам строго вывести про то, что должна операция и про арифметику и проч.
Хорошо. Давайте просто про несоответствие Оракла стандарту в данном случае :) Что совой об пенек, что пеньком об сову...
15 июл 10, 14:41    [9109919]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Favn
Если бы я хотел усилить свое утверждение, я бы и сам с эти справился :)

Но без этого непонятно в чем различие взлядов.

Favn

null может означать и отсутствие значения (как результат внешнего объединения), но это выходит за рамки обсуждаемой "фичи" Оракла.

Не нуно нас дурачить. Это не выходит за рамки обсуждения про null.
И не как результат внешнего соединения. Я приводил примеры как результат проектирвания.
В "полях".

Favn

В полях же БД он изначально означает именно unknown, т.е. неизвестно, не определено. Это следует из логических операций над ним.

Он назван NULL(это же название то же чего-то да значит). А unknown в логических операциях.

Favn

Сравнение любого определенного значения с "пусто" должно возвращать определенный ответ true/false, а вовсе не "unknown", как сравнение с null.

Смотря что стоит за этим "пусто". Что будет если сравнивать значение с не определено (не имеет смысла). "пусто" всего лиш факт что не заполнено, без указания подробностей (не известно значение), не пределено.

Favn

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

За разрешение спасибо. А пример я вам приводил. Проектировщик выбирает меньшее из зол.

Favn

Его можно использовать как "свойство отсутствует". Как и любое другое значение, написав default '' например. Просто default null принимается по-умолчанию, и все.

Вы думаете, что для значение есть, но не известно NULL ,был изначально, а для свойство отсутсвует его можно использовать, чем_то отличается то отого, что его можно использовать в обоих вариаентах?
Т.е. Вы почти согласились с моей позицией, но не не до конца. Отличие в изначальности? Ну так мы же не истроики? Мало для чего что изначально было? Ить имеет значение для чего оно в текущем моменте.
Кста применение default null зависит от чего-то другого и может подойти обоим вариантам.

Favn

Прошу прощения, но фразу не понял. "Кто на ком стоял?" (с)

Ничего страшного. Она была актуально пока я думал, что Вы признаете за null тока одну возможность в МД: значение есть, но не известно. Как только Вы отказались от этого наше расхождение стало символическим( или по историческому аспекту воапроса).


Favn

Просто в классическом SQL нет типа boolean.

Как в запросах происходит выборка по условию (в WHERE)? Ведь запись в результат попадает только если условие True? Или что там еще есть? Это не зависит от СУБД. Если FALSE или UNKNOWN, то не возвращает. Отличить их можно тем, что если поменять условие на его отрицание, то в первом случае станет TRUE и запись попадет в выборку, а UNKNOWN снова - UNKNOWN и запись не попадет в выборку.


Favn

Думаю, что в Оракле - тоже, раз в DB2 его ввели недавно для совместимости с ним. Я склонен согласиться с ними обоими :)

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


Favn
Как раз к "отсутствует" логика с NULL не подходит, т.к. результат равенства/неравенства с "отсутствует" вполне определен - либо значение там есть, либо его там нет :)

Отсутсвет значение в плане бессмыслено, вполне можно считать не известным. Так или иначе при моделировании значение не определено можно приспособиться к такой логике. Возможно это луче чем значение. Другое дело, что, возможно, чище было если бы кроме NULL была бы какое нибудь EMPTY. И логика какяч-нить четырехзначная. Впрочем, может в этом есть недостатки. Наверное это вопрос изучался лет 30 а то и более назад.

Favn
Я придерживаюсь другого подхода - применяю NULL именно в значении "unknown", неизвестно. И синтаксис с логикой тогда подходят, и с моделями - никаких несоответствий.
А значение "пусто" можно обозначить любым подходящим из множества значений поля, например '' для строк написав default ''.

Ну тут кажный как может. Строка не подошла. default '' ниче не дает (кроме того что зваполнять не надо, но это не принципиально).

Favn

Связь простая - раз в общем случае NULL может означать "unknown", конкатенация с ним по логике тоже должна вернуть "unknown", т.е. NULL. Т.к. результат остается неизвестным. А в Оракл, по факту результата операций, null/'' означает unknown в операциях сравнения и пустую строку - в конкатенации. В чем и противоречие.

Ну опять Вы начинаете про должна? А в частном случае NULL выглядит как пустота. Тада что?
Есть синтаксис, а есть модели где он применяется. Вот есть парни которые выбирают синтаксис чтобы он подошел большему числу моделей. А мы пытаемся строго вывсти? А где гарантии, что наши предположения верны?

Favn

Семантичность пустой строки полностью зависит от внешнего отн. БД приложения и может означать именно "пустое, определенно пустое значение", например.

Может то может, но слабовато буит. А для не строковых типов? Не лучше ли специальное понятие EMPTY.
Я скептически отношусь к использованию пустой стпроки в этом плане в СУБД где она есть. Полумеры (не все типы). И там еще что-то, по моему, не пошло.

Favn

В арифметике нет NULL. Но в SQL есть арифметика. Именно в контексте ее использования в SQL я ее и "привлекал". Ну, разве что с делением увлекся :) Хотя арифметику к этому обсуждению приплетали и до меня, можно считать это ответом.

Не не пойдет такое привлечение. Это только уведет в сторону. Может там еще про Геделя вспомнить из-за NULL?

Favn

Минуточку, не надо выдергивать из контекста. Я писал только о пустых строках в ЯП вообще и в SQL в частности. "Обобщенная роль пустых строк в мироздании" меня никогда не интересовала.

Так может пойти дальше и на роль пустых строк забить в МД? Оставить их только в ЯП?

Favn

Хорошо. Давайте просто про несоответствие Оракла стандарту в данном случае :) Что совой об пенек, что пеньком об сову

Ну знает это другой вопрос. Стандарты все равно полностью не все соблюдают, да и стандарты не обязательны и могут меняться. Это процесс. Другая тема.
15 июл 10, 16:14    [9110890]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Favn
web_fox
О боги! Откуда вы это всё придумали??? Из MMX-инструкций, устройства FPU?
Какое ещё множество какой такой неопределённостью расширить?
По правильному любые операции с NULL должны приводить к исключению. Если ваша программа дошла до умножения или сложения чего-то с тем, чего не существует - это ошибка при реализации бизнес-логики, это как в сях записать что-то в память по неинициализированному указателю, просто ошибка.
Мда. Еще один. "Дорогая, их тут тысячи!" (с)
NULL в процедурных языках с C-подобным синтаксисом не имеет никакого отношения к NULL в SQL. В первых - это пустой указатель (ссылка в Java и т.п.), во втором - unknown, неизвестное (неопределенное) значение.
Различить их очень просто - по операции сравнения.
Сравнение переменной с NULL в процедурных языках дает true или false в зависимости от содержимого переменной. Т.е. NULL является вполне определенным (пустым) значением.
Сравнение с NULL в SQL там, где есть тип boolean, даст тоже NULL вне зависимости от значения сравниваемого поля. И в любой СУБД не даст ни true, ни false. То есть значение unknown, не определено, и любая операция с ним (кроме проверки на NULL) естественно приведет к unknown результату.
Из логики с NULL следует, что у этих языков разные первичные определения NULL, т.е. аксиоматика.
web_fox
NULL - это просто флаг(!), который говорит, что значения нет. Как я уже сказал, фактически это отдельное(!) свойство, а не отдельное значение. Это, если хотите, атавизм синтаксиса современного SQL, потому что синтаксически присваивается по значению как обычное значение, хотя реально является отдельным самостоятельным свойством, например: !Apple.isNull() ? Apple.GetColor() : RaiseException().
При чем тут флаг? Опять путаете смысл NULL в SQL и его интерпретацию в прикладных библиотеках конкретного языка, в синтаксисе которого возможность unknown значений отсутствует.


Я внимательно прочитал что вы написали и вот что пишется в документации "самой лучшей субд":
Самая лучшая субд
A database column or a SQL expression can have a value, or it can have a special status called null. A null means the absence of a value. A numeric value or a special string encoding cannot be used to indicate a null, since all allowable numeric or string values are reserved for actual data

Это просто флажёк такой "нет значения". Всё просто до безобразия. Поэтому не нервничайте.
Это ФИЗИЧЕСКИЙ смысл NULL. Он один. Есть разные костылики, например, GROUP BY считает NULL=NULL и прочие, - их много, если покопать. Костылики появляются везде, где кому-то что-то показалось удобным и он решил прилепить костылёк

Oracle, например, предлагает такие стандартные интерпретации: missing, unknown, inapplicable data. А как вы там лично интерпретируете ОТСУТСТВИЕ ЗНАЧЕНИЯ, - как "неизвестное" значение, "непонтяное", "неприятное", "плохое", "противное" и т.п. - это на ваш вкус
15 июл 10, 20:01    [9112160]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Bogdanov Andrey
web_fox
По правильному любые операции с NULL должны приводить к исключению.
Я верно понял вашу мысль о том, что все СУБД работают совершенно неправильно? Или вы можете назвать СУБД, которая при конкатенации с null выдает исключение?
А если все СУБД работают неправильно, то вопрос лишь в том, какая из "неправильностей" удобнее, привычнее и т.п.


Вы - директор. Новый груз пришёл, но помещения НЕТ. Вам какая больше нравится ситуация:

1. Кладовщик, посмотрел, что склада нет. Ничего страшного, написал в "принято товара": "неизвестно". И пошёл себе дальше работать как ничего не случилось. Вам надо проверять, на написал ли этот XXX в накладных "неизвестно", чтобы вставить ему.

2. Кладовщик, посмотрел, что склада нет. Пришёл к вам и говорит: "Босс, исключительная ситуация, - товар пришёл, а помещения нет".

Мне нравится второй вариант.
15 июл 10, 21:02    [9112402]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67415
Блог
web_fox
1. Кладовщик, посмотрел, что склада нет. Ничего страшного, написал в "принято товара": "неизвестно".

Хуже другое: он взял регистр товаров на складе, и в графу "розовых слоников детских" написал 28 + неизвестно = неизвестно. Забыл число "28" и пошёл дальше работать.
15 июл 10, 21:13    [9112435]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
softwarer
web_fox
1. Кладовщик, посмотрел, что склада нет. Ничего страшного, написал в "принято товара": "неизвестно".

Хуже другое: он взял регистр товаров на складе, и в графу "розовых слоников детских" написал 28 + неизвестно = неизвестно. Забыл число "28" и пошёл дальше работать.

В яблочко.
15 июл 10, 22:00    [9112561]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Yo.!
Guest
Favn
Именно это я и утверждал.


пересказывать, что утверждалось, когда есть текст на предыдущей странице мне лень. еще раз, теперь что я имел ввиду фразой "процедурный код сторед процедуры на SQLJ выполняются сторонней жава машиной, которая о принятых в SQL DB2 правилах не в курсе" надеюсь ясно ?

Favn

1. SQLJ (статика) в Оракле преобразуется в вызовы JDBC (динамика), т.е. является именно syntax shugar.

то что IBM называет JDBC type 2 driver оракл завет JDBC Server-Side Internal Driver

Favn
2. JVM в Оракл является внешней по отн. к SQL процессору (как и PL/SQL VM), но управляется ядром. При этом имеет свою область памяти, настраиваемую отдельными параметрами.


я бы сказал так: оракловая JVM ровно на столько внешняя на сколько SQL, PL/SQL внешний для ядра субд. по мне так спроектированная под нужды субд, интегрированная в структуру SGA JVM существенно отличается от работающей во внешнем процессе JVM общего назначения.

Favn
И мне до сих пор интересно, выполняется ли для SQLJ, т.е. статического SQL, валидация с изменениями схемы БД в Оракле. Из-за трансляции в JDBC у меня есть сомнения на этот счет.

не выполняется. там создается такой же profile как и в дб2, структура этого profile файлика описана в стандарте. просто перед созданием profile валидируется SQL.

возвращаясь к SQLJ, в оракле есть два варианта:
1. все то же самое, что и у дб2, все согласно стандарту. к статик SQL прислоняется любая JVM, рядом кладутся profile, только JDBC через который дергается база зовется чуть по другому.
2. не совместимая со стандартом загрузка SQLJ как единое целое в субд, где выполняется под интегрированной в ядро JVM. второй вариант естественно гораздо быстрее. думаю тут просто SQLJ транслируется в обычную Java stored procedure. вот они, по моему, имеют такие же зависимости как и pl/sql
все, оффтопик по sqlj завязываю.

возвращаясь к нашим нулам: для меня выглядит дико когда говорят, что когда я обрабатываю нулл языком сторед процедур, то это один нулл, а когда я обрабатываю ту же сущность из той же таблицы, из того же поля но уже на уровне апп-сервера это уже какой-то другой нулл.
15 июл 10, 22:18    [9112582]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Вообще, само наличие правил работы с NULL является типичным примером old school-стиля программирования, когда все функции возвращали коды, типа 0 - всё хорошо, 1 - нет прав, 2 - неверно задано имя файла и т.д. Типа операция выполнится по-любому, а ты (если будешь любезен) должен получить код возврата и... обработать его. Хотя, можно не обрабатывать! Не обрабатываешь коды возврата - ничего страшного, программа будет работать дальше, а там как повезёт.

Шли годы. Умные люди поняли, что такой подход позволяет писать тот самый "говнокод", чем люди удивительно часто пользуются. Подход с исключениями не позволяет писать говнокод, сразу же обрывает выполнение программы и говорит: "товарищ, ты написал Говнокод",

ибо ложить шифер на непостроенный гараж есть "говнокод".
15 июл 10, 22:29    [9112596]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
так, к слову...
Guest
softwarer
Когда я учил людей Oracle, я всегда говорил им одну фразу: "Запомните одно-единственное слово, dba_views...
Хм... Можно было учить получше :-) - DICTIONARY или его синоним DICT

softwarer
Вообще-то Oracle изначально был написан на ассемблере.
Да, самая первая коммерческая версия. Но начиная с незапамятных времен и версии 3 - на C (компилятор C был баксов на 100 дешевле компилятора Pascal)
18 июл 10, 20:05    [9121877]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67415
Блог
так, к слову...
Хм... Можно было учить получше :-) - DICTIONARY или его синоним DICT

Наверняка можно было лучше, и не только в этом.

так, к слову...
Но начиная с незапамятных времен и версии 3 - на C

Вполне вероятно, что в целях совместимости уже не захотели менять формат. Также вполне возможно, что осознанно решили использовать более прогрессивный.
18 июл 10, 20:39    [9121937]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
DPH3
Guest
Yo.!

то что IBM называет JDBC type 2 driver оракл завет JDBC Server-Side Internal Driver


Это, хм, к вопросу о поддержке Ораклом стандартов )
JDBC driver type {1-5} - это часть стандарта Java. IBM честно указывает, какому стандарту соответствует предоставляемый драйвер.
Oracle, как всегда, стандарты игнорирует...
19 июл 10, 04:33    [9122595]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
DPH3
Yo.!

то что IBM называет JDBC type 2 driver оракл завет JDBC Server-Side Internal Driver


Это, хм, к вопросу о поддержке Ораклом стандартов )
JDBC driver type {1-5} - это часть стандарта Java. IBM честно указывает, какому стандарту соответствует предоставляемый драйвер.
Oracle, как всегда, стандарты игнорирует...

А мужики то не знают.
19 июл 10, 10:30    [9123268]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Alexander Ryndin
DPH3
Yo.!

то что IBM называет JDBC type 2 driver оракл завет JDBC Server-Side Internal Driver


Это, хм, к вопросу о поддержке Ораклом стандартов )
JDBC driver type {1-5} - это часть стандарта Java. IBM честно указывает, какому стандарту соответствует предоставляемый драйвер.
Oracle, как всегда, стандарты игнорирует...

А мужики то не знают.

Типа шутка? Чуть выше о том и говорят, что стандартная вещь названа по своему.
19 июл 10, 10:56    [9123476]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
iscrafm
Alexander Ryndin
DPH3

Oracle, как всегда, стандарты игнорирует...

А мужики то не знают.

Типа шутка? Чуть выше о том и говорят, что стандартная вещь названа по своему.
эм... придумывать свои названия и игнорировать стандарты - это 2 разные вещи.
кроме того, по ссылке можно видеть, что у Oracle есть 2 драйвера четвертого типа (JDBC Thin client-side driver и JDBC Thin server-side driver). как их называть? мне кажется, что все логично.
19 июл 10, 13:10    [9124518]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
так, к слову...

softwarer
Вообще-то Oracle изначально был написан на ассемблере.
Да, самая первая коммерческая версия. Но начиная с незапамятных времен и версии 3 - на C (компилятор C был баксов на 100 дешевле компилятора Pascal)


не потому что дешевле, а потому что портировать паскалевский Ораkл на 28 ОС не удалось бы.
20 июл 10, 00:18    [9128218]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67415
Блог
Lepsik
потому что портировать паскалевский Ораkл на 28 ОС не удалось бы.

Столь же сомнительное утверждение, как и предыдущее.
20 июл 10, 00:42    [9128266]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Favn
Member

Откуда:
Сообщений: 585
vadiminfo
Но без этого непонятно в чем различие взлядов.
Ок. Определимся. Я считаю, что строковый NULL в Оракле ведет себя как "пустая строка" в строковых операциях и как общепринятый NULL в остальных, что бы он там не значил. И это:
1. Внутренне противоречиво.
2. Противоречит поведению базового типа varchar во всех остальных РСУБД.
Т.е. является архитектурной "багой", проистекающей из совпадающего способа хранения NULL и '', традиционно для архитектурных "баг" (не только Оракла :) ) замаскированной под "фичу". Причем "фича" эта deprecated самим Ораклом.

В дополнение к этому я считаю, что изначальным значением NULL в SQL в описании полей было именно "неопределенное значение", и это следует из логичесих операций с участием NULL. Но этот вопрос к данной дискуссии не относится. О "неопределенности" я говорил именно в свете того, что раз NULL может означать неопределенность, толковать его именно как пустую строку неправомерно.
vadiminfo
Не нуно нас дурачить. Это не выходит за рамки обсуждения про null.
И не как результат внешнего соединения. Я приводил примеры как результат проектирвания.
В "полях".
Integer или char(1), например, при проектировании можно использовать для каких-нибудь флагов. Это не значит, что integer и char вводились именно для флагов.
vadiminfo
Он назван NULL(это же название то же чего-то да значит).
Да, NULL. А имея в виду именно "пустоту" могли бы назвать VOID, например.
vadiminfo
Т.е. Вы почти согласились с моей позицией, но не не до конца. Отличие в изначальности? Ну так мы же не истроики? Мало для чего что изначально было? Ить имеет значение для чего оно в текущем моменте.
По моему мнению, принципиальное отличие не в "изначальности", а в результатах логических операций. Если использовать логику кроме is null в запросах с этим полем не предполагается, NULL может значить что Вам угодно. Но не надо делать из частного случая общее правило.
За сим теоретический спор с привлечением лингвистики и философии предлагаю закончить в виду полной бесперспективности :)
И сосредоточится на конкретном толковании NULL varchar в Оракле и остальных РСУБД.
vadiminfo
Ну знает это другой вопрос. Стандарты все равно полностью не все соблюдают, да и стандарты не обязательны и могут меняться. Это процесс. Другая тема.
Когда речь идет о расширениях SQL - безусловно. Но мы говорим о базовой операции || над базовым же типом varchar.
20 июл 10, 18:20    [9133436]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Favn
Member

Откуда:
Сообщений: 585
web_fox
Я внимательно прочитал что вы написали и вот что пишется в документации "самой лучшей субд"...
Это просто флажёк такой "нет значения". Всё просто до безобразия. Поэтому не нервничайте.
Да мне, собственно, нервничать ни к чему. Тем более из-за цитаты из документации продукта, который я пока не использую и багу в котором обсуждаю :)
web_fox
Вообще, само наличие правил работы с NULL является типичным примером old school-стиля программирования, когда все функции возвращали коды, типа 0 - всё хорошо, 1 - нет прав, 2 - неверно задано имя файла и т.д. Типа операция выполнится по-любому, а ты (если будешь любезен) должен получить код возврата и... обработать его. Хотя, можно не обрабатывать! Не обрабатываешь коды возврата - ничего страшного, программа будет работать дальше, а там как повезёт.
Опять за свое. Какие "коды возврата" в декларативном, непроцедурном языке SQL? Какой-такой new scool в SQL, использующий исключения? Куда, по-вашему, должно выводить исключение в запросе? В каком месте запроса обрабатываться? Где там стек вызовов?
web_fox
Шли годы. Умные люди поняли, что такой подход позволяет писать тот самый "говнокод", чем люди удивительно часто пользуются. Подход с исключениями не позволяет писать говнокод, сразу же обрывает выполнение программы и говорит: "товарищ, ты написал Говнокод",
ибо ложить шифер на непостроенный гараж есть "говнокод".
В контексте обсуждения - бред полный.
За долгие годы работы с C++, например, я худо-бедно разобрался с тем, что такое "исключения". Может, "умные люди" подскажут, в каком месте именно SQL я должен их использовать?
20 июл 10, 18:30    [9133468]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 13 14 [15] 16 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить