Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Всё больше и больше уважаю PostgreSQL. Там много весёлого, зато отсутствует игра в чистую математику. В отличие от Крутой База Данных одной Большой Фирмы.

В пятницу коллега показал очередной шедевр.

Есть условие, скажем,

WHERE

A * 100000 + B = C

Оно точно-точно выполняется с математической точки зрения, но SELECT выдаёт пустую таблицу. То есть, A,B и C - правильные, а на выходе ничего.

Что надо сделать, чтобы исправить ситуацию?


Правильно. Нужно просто добавить пустоты.

WHERE

A * 100000 + B + 0 = C

прекрасно работает и выдаёт всё, что нужно.


Какие, нафиг, монады-шмонады. Чистый дзен.

Comments

[cross-join.livejournal.com]

Не воспроизводится на PostgreSQL 9.3

CREATE TABLE t1
(
  id integer NOT NULL,
  a integer,
  b integer,
  c integer,
  a1 double precision,
  b1 double precision,
  c1 double precision,
  CONSTRAINT pk_t1 PRIMARY KEY (id)
);
INSERT INTO t1
VALUES(1, 2, 3, 200003, 2.0, 3.0, 200003.0),
(2, 5, 5, 500005, 5.0, 5.0, 500005.0);

SELECT * FROM t1 WHERE a * 100000 + b = c;
SELECT * FROM t1 WHERE a1 * 100000 + b1 = c1;

DROP TABLE t1;

[vit-r.livejournal.com]

Естественно, не воспроизводится. Это не PostgreSQL, а Крутая База Данных одной Большой Фирмы. И условия там похитрее.

[cross-join.livejournal.com]

Оракляндия?
Там до сих пор нет типов "целое", "вещественное".

[vit-r.livejournal.com]

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

[cross-join.livejournal.com]

Ну, все что не "биг-3" - не крутая фирма :)

[vit-r.livejournal.com]

Пожалуйста, без наводящих вопросов.

[swamp-agr.livejournal.com]

В Oracle не используют ФП целиком как есть.
Вместо этого там пилят C++/Java с использованием элементов ФП.
Это как ехать в трамвае и утверждать о том, что автобусы-то на самом деле плохие, никуда на них не уедешь.

[vit-r.livejournal.com]

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

[swamp-agr.livejournal.com]

Ага, вот она связь.
Ну, честно говоря, PostgreSQL смотрит на неё и вбирает в себя передовые фичи Оракла.. Взять те же материализованные представления, которые впервые появились у задающих тренд..
Однако там появляются, помимо прочего, очень интересные фичи, которых у монстра нет.
Взять ту же работу с JSON против работы с избыточным транскорпоративным недолиспом под названием XML.

Upd. И потом: Oracle - в офисе, PostgreSQL - дома.

[vit-r.livejournal.com]

У нас кластер, базирующийся на PostgreSQL.

[swamp-agr.livejournal.com]

Молодцы! :-) Ещё много неизведанного таят базы, раз до них дотянулись интересные разработчики, которых следовало бы пороть.

[vit-r.livejournal.com]

Таких шуток, как приведена выше, в кластере не замечено. А остальное - болезни роста.

[thedeemon.livejournal.com]

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

[vit-r.livejournal.com]

Дело, естественно, не в отсутствии строгой типизации, а в отсутствии кое чего другого кое-у кого между ушами.

Потому что при одном наборе A,B,C всё работает, а при другом - прекращает.

[sab123.livejournal.com]

Плаваюшие числа вообще нельзя сравнивать на равенство. Вместо него надо делать плюс-минус сигма.

[vit-r.livejournal.com]

Первым делом, на одной и той же машине равные числа должны быть равными.

Вторым, там ничего после запятой нет. Правда, если добавить в число с нулями десятичный нуль, тоже всё начинает работать.

Короче, совсем наоборот к той идее, которая приходит в голову.

[sab123.livejournal.com]

Если печатается одинаковое десятичное представление (которое всегда делается с округлением), это не значит, что настоящие двоичные значения равны. Добавление 0, похоже, вызывает округление, которое уравнивает двоичные значения.

Разрядная сетка мантиссы-то не переполняется?

Но в-общем - неча пенять на СУБД коли нет понимания работы с плавающими числами.

[vit-r.livejournal.com]

Если печатается одинаковое десятичное представление (которое всегда делается с округлением), это не значит, что настоящие двоичные значения равны.

Ну что за люди. Почему предполагается, что я в чём-то не разбираюсь? Если сказано баг, значит все возможные варианты проверили.

Разрядная сетка мантиссы-то не переполняется?

Она не может переполняться. Тем более, там всё целочисленное. Но даже для вещественного не могла бы при таких значениях.

[cross-join.livejournal.com]

Таки в СУБД строгая типизация.

[vit-r.livejournal.com]

Угу. Если int в varchar не засовывать.

[cross-join.livejournal.com]

Если что угодно в void* не засовывать.

[vit-r.livejournal.com]

Ну да. Явное преобразование типов исправляет любые попытки типизации.

[cross-join.livejournal.com]

Тем не менее, деление сред на сильно и слаботипизированные позволяет отнести СУБД к первым, а не ко вторым.

[-oxpa-.livejournal.com]

mssql? db2? firebird?
Но вообще, конечно, прекрасно.

[vit-r.livejournal.com]

Не-а. Но, если даже кто-то назовёт, я подтверждать не буду.

Это большая серьёзная база данных. На ней Big Data бегает.

[-oxpa-.livejournal.com]

ну теперь-то я точно знаю: http://www.mysql.com/why-mysql/bigdata/ ;)

[vit-r.livejournal.com]

Нет, это не MySQL. Я ещё не видел камикадзе, ставящих на MySQL серьёзные финансовые задачи.

[-oxpa-.livejournal.com]

ладно, хорошо, буду считать шутку про bigdata на mysql слишком тонкой...

[vit-r.livejournal.com]

Я просто про то, что было бы это в MySQL, было бы не интересно.

[bofhland.livejournal.com]

Teradata, небось!

[esc.livejournal.com]

Я попытался представить, как оно может быть. Если поле B, допустим, строковое, и база вместо сложения начинает делать конкатенацию. Но в таком случае это не математика виновата, а плохое проектирование базы. Да и писатель запроса должен по-хорошему знать, откуда он тягает и включить явное преобразование типа вместо волшебного нуля. И всё равно не объясняет, почему дополнительный ноль помогает.

Что ещё может быть? Вылезание за границы типа. Слева int, справа bigint. Опять же теоретизирую. И снова неясно, почему помогает ноль. И снова разработчику желательно знать типы своих данных.

Короче, я как СУБД-шник заинтригован предельно.

[vit-r.livejournal.com]

Что ещё может быть?

Баг, естественно. При одних значениях A, B и C всё нормально, при специфических - фиг.

А ноль - это такое заклинание, которое практически всегда помогает.

[esc.livejournal.com]

Баг в математике? Настоящий? У солидной известной фирмы? На который до сих пор не напоролись тысячи разъяренных пользователей? Что-то с трудом верится.

[vit-r.livejournal.com]

Сказал же, условия специфические. Но не такие интересные как с 0/null (http://vit-r.livejournal.com/776364.html)

[esc.livejournal.com]

Ну! Я ж говорил, что числа в строках. :) С таким подходом немудрено наловить полный карман блох.

Видимо речь не о СУБД как таковой, а о неком продукте, который ставится надстройкой на настоящую СУБД. Типа как SAP. (Не о них ли речь, кстати?) Поэтому всё что можно и нельзя хранится в строчках. Вот например мы из SAP ECC сосём данные. У них все ID - числа, хранимые в строках varchar(10). Поэтому их добивают слева нулями для правильной сортировки. Но отображают на экране без нулей. Мы долго втыкали, что это и зачем оно так.

Судя по операции в примере, речь в нём тоже идёт о каком-то составном айдишнике. Зачем ещё может быть нужна такая специфическая математика. :)

[vit-r.livejournal.com]

Я ж говорил, что числа в строках

Это в тот раз. В этот раз типы для чисел нормальные.

Видимо речь не о СУБД как таковой,

Отнюдь. А надстройка - это как раз то, что мигрирует. К SAP интерфейс, кстати, тоже есть. Со всеми радостями, оттуда приходящими.

[norguhtar.livejournal.com]

Кстати говоря в PostgreSQL некоторое время не было строгой типизации и он пытался угадывать как преобразовать типы. До 8 версии если мне память не изменяет. Далее сказали хватит разврата и заставили всех указывать явное преобразование типов.

[vit-r.livejournal.com]

Так я уважаю актуальную версию (-_^)

[anonim-legion.livejournal.com]

Извиняюсь, а про COALESCE вы уже знаете, да?

[anonim-legion.livejournal.com]

И, вы могли бы сделать нечто вроде

select a, b,c , ( A * 100000 + B + 0) as test

?

Чтобы было ясно, о чем речь.

[vit-r.livejournal.com]

Всё, что надо, уже сделано. Но это информация не публичная.

[vit-r.livejournal.com]

По-моему, даже с "извиняюсь" это хамство.

Если бы там было неравенство всегда, можно было бы о чём-то говорить. Но феномен возникает только при специфичных значениях для A, B и С.

[vit-r.livejournal.com]

Вы общаетесь с профессионалами. Там баг на определённых значениях.

[bganiev.livejournal.com]

хамство тут только с вашей стороны!
вы удаляете неугодные вам камменты!

[vit-r.livejournal.com]

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

[bganiev.livejournal.com]

еще раз.
=, *=, =*
что скажете?

[vit-r.livejournal.com]

Зачем мне что-то говорить?

Я знаю о чём я пишу, знаю в чём ошибка. То, что информация не полная, так остальное ДСП.

А кто хочет викторин, может устраивать в другом месте.

[vit-r.livejournal.com]

Бан.

И, если такое добро сюда полезло, пора закрывать лавочку.