davydoff пишет:

> 1. Прокомментируйте, пож, выдержку ниже. Не очень понятно, что за такая
> 'performance penalty'. К сожалению, могу привести только этот кусок
> текста, так как получил его по почте.
>
> автор
> As of version 2.04, the Sybase DATETIME and MONEY datatypes can be kept
> in their native formats in both the Sybase::DBlib and Sybase::CTlib
> modules. In addition, NUMERIC or DECIMAL values can also be kept in
> their native formats when using the Sybase::CTlib module. This behavior
> is normally turned off by default, *because there is a performance
> penalty associated with it*. It is turned on by using package or
> database handle specific attributes.

Комментирую: это ерунда.
Тут видимо обсуждаются пакеты для Perl-а.
Там (как и в любом другом клиенте, использующем CTLib)
данные могут быть представлены в виде строк или в виде
значений типов DATETIME, MONEY, NUMERIC or DECIMAL.
Эти типы не встроены в язык Perl, а являются структурами,
поддерживаемыми библиотекой CTLib common client and server library.
Поэтому при обращении к операциям этих типов будут вызываться
функции этой библиотеки и это потенциально может быть медленнее,
чем если бы это была перловая строка, которая встроена в язык
и вроде бы должна работать быстрее. Видимо, поэтому в Sybase::CTlib
есть два режима работы, когда клиентские переменные используются
как строки Perl, либо как native- значения (не все, поскольку
типы типа String, int и т.п. будут использовать встроенные типы
данных Perl).

Почему это все ерунда - потому что у пользователя нет выбора,
думаю. Если ему НЕ НУЖНЫ операции с полями данных типа numeric
и прочими, то можно использовать строковые представления.
Если операции с этими типами данных нужны на клиенте,
то делать нечего, придется использовать CTLib.

На самом деле язык Perl такой медленный сам по себе, что его уже
ничто не спасёт (это наполовину шутка).

> 2. Дайте пож ссылку на информацию о неявных преобразованиях типов в ASE.
> Интересует вопрос, касающийся преобразования числовых констант в
> операциях сравнения (инструкция where). К примеру, в какой тип будет
> преобразована константа 10.3, если столбец 'value' имеет тип numeric(5,3):
>
> автор
> select value from table where value < 10.3

Здесь 10.3 имеет тип numeric


Немногие знают, что в ASE (в Transact SQL) есть КОНСТАНТЫ типа numeric.
А сделано так потому, чтобы до тех пор, пока константа не присвоилась
какой-то переменной, не терялась бы ее точность.
Также есть константы типа MONEY


и константы типа double float



Заметьте, что последнее поле имеет тип NUMERIC, а 'f' в конце ошибочно
итретпретируется как название выводимого поля. Видимо, это баг в парсере
TSQL, хотя и безобидный.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

> Что касается CTlib, вроде бы есть также C++ - версия.

Так только и есть С-версия, другой нету.
Только С, а не С++. С++ - нету.

Ни разу не
> использовал эту библиотеку, так что мне не очень понятно, что означает
> native format в C++.

Типы данных в том представлении, в котором они храняться в том
числе в самом ASE.

Особое представление, к примеру, структура с двумя
> полями - целая и дробная часть...?

Ну, там сложнее немного все, NUMERIC представляется как
число, хранимое в 256-ричной системе счисления, но это не важно.

В любом случае, проигрыш в
> производительности при конвертации в C++ - пренебрежимо мал в сравнении
> со всем остальным, IMHO.

Да, именно.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

> Спасибо за уточнение. Добавлю, что также существуют реализации на perl
> и, вроде бы, ruby. Возможно, что можно найти реализации под другие языки
> программирования.

Это не реализации всё. Это - так называемые линки. Модули языка, которые
осуществляют вызовы native C кода. А сама реализация - на C, в виде
разделяемой библиотеки.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

> Оказывается, что sizeof(CS_NUMERIC) = 35. Неужели сервер пересылает на
> клиент numeric числа, используя 35 байт?

Да. Не, конечно самое фиговое - что оно там фиксированной длины, но
не все 256-ричные цифры всегда используются.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

> Пока не очень понятно, как преобразовывать эту структуру. Пытаюсь
> разобраться с функцией cs_convert.

Вот именно, cs_convert-ом.

В целом, API содержит минимальный
> набор функций. С одной стороны это хорошо, но с другой стороны
> доставляет определенные сложности в разработке. Интересно, есть другие ,
> более простые способы выполнить преобразование без использования ф-и
> cs_convert?

Нет, нету. В смысле, в API. Если сам напишешь, то будет.

Буду рад, если кто-нибудь приведет простой пример кода
> преобразования с помощью этой функции.

На счёт "простой" - это ты погорячился, там такого не бывает, ну вот
"обычный" можно найти.


В комментарии там попытка перевести в строку самому.
Неудачная.
Я думал, там BCD, но там не оно, а 256-ричное число.
Его бы и можно было бы переверсти самому, но
там загвоздка в том, где они помещают десятичную точку,
это сложно вычислить. Если бы это знать, то всё было бы ОК.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:
> Мда. Это серьезный аргумент в сторону использования float!

Нет, уж извини. Нужна тебе точная арифметика - используй NUMERIC.
Это не техническими требованиями определяется, а функциональными.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

> MasterZiv - большое спасибо за пример. Еще раз убедился, что двигаюсь в
> правильном направлении. Я пытаюсь сконвертировать double в CS_NUMERIC,
> но функция cs_convert выдает ошибку.

Да боюсь, что в неправильном. Double бессмысленно конвертировать в NUMERIC.
Потому что DOUBLE - неточный тип данных, а NUMERIC -точный.
Я уже не помню, возможно ли вообще такое преобразование в CTLib, если
что - можно посмотреть в документации или вызвать функцию cs_canconvert()
(или cs_will_convert() ?), но если нельзя, то надо это делать через
строку:

[fix]
DOUBLE => STRING => обрезать до нужного кол-ва знаков => NUMERIC
[/fix]

> Контекст создал и инициализировал. Соединение с БД с созданным
> контекстом происходит.

Вот же блин, как тебе плохо-то!
Надо бы тебе выслать пример.
Хотя кстати примеры есть в стандартной поставке.
Ну я могу тоже дать (другой).
Но в понедельник.

Для cs_convert соединение вовсе не обязательно устанавливать,
и без соединения должно работать.

Команды выполняются, а cs_convert выдает ошибку (
> retcode = 0).

>
> double val(100.2345);
> CS_NUMERIC num;
> CS_INT len(10);
>
> CS_DATAFMT srcfmt;
> srcfmt.datatype = CS_FLOAT_TYPE;
>
> CS_DATAFMT tgtfmt;
> tgtfmt.datatype = CS_NUMERIC_TYPE;
> tgtfmt.precision = 10;
> tgtfmt.scale = 5;
>
> CS_RETCODE ret = cs_convert(ctx, &srcfmt, &val, &tgtfmt, &num, &len);
> if (ret != CS_SUCCEED) {
> printf("RET CODE: %d\n", ret);
> EXIT_ON_FAIL("cs_convert is failed");
> }

Да, наивный код. Работать кажется не будет.
Ладно, до понедельника.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

Бессмысленно - если не
> установлены правила конвертации.

Бессмысленно, на мой взгляд, вообще, по идеологическим
соображениям. Вот НИ РАЗУ В ЖИЗНИ мне это ещё не понадобилось.
Потому что если данные точные - они точные, а если приблизительные
- то приблизительные. Их не зачем скрещивать. Они нигде не пересекаются.

Не можете более детально описать, зачем вам это надо ?

Единственно, что пока непонятно - мой
> код не работает, если не "обнулить" структуру CS_DATAFMT.

Ну потому что надо обнулять.
Так написано в документации.

Пример вам нужен еще ?
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

> так как клиент работает в числами double. Если хранить числа в БД в виде
> numeric, то в клиенте их надо будет преобразовывать в double. Я замерил

Да нет же, НЕТ !
НЕЛЬЗЯ ТАКОГО ДЕЛАТЬ НИКОГДА !

numeric -точный тип данных. Float, fdouble - приблизительные.
Если вы будете между ними преобразовывать, у вас будут нарушения доменной
целостности, и

> производительность этого преобразования: 1 сек - 1М преобразований на
> AMD Opteron 250, CPU 2400MGz. Я считаю, что это не быстрое
> преобразование, но вклад в общую производительность вряд ли будет
> существенным.

Вы, еще раз говорю, не тем занимаетесь. Если у вас есть требование
использовать точную арифметику, то это - функциональное требование.
А не техническое. Если оно у вас есть, то вам ВЕЗДЕ НУЖНО ИСПОЛЬЗОВАТЬ
ИМЕННО NUMERIC-и (ну или аналоги, money, decimal).
У вас НЕТ ВЫБОРА. Потому что float-ы - неточные,
и точность вашу нарушат. Причем это произойдет, если ХОТЯ БЫ ГДЕ-ТО,
либо в БД, либо в клиенте, либо по дороге от первой ко второму или обратно,
вы ХОТЯ БЫ ОДИН РАЗ используете неточную арифметику ДАЖЕ ДЛЯ ХРАНЕНИЯ
данных, а не только для вычислений.
Posted via ActualForum NNTP Server 1.4

davydoff пишет:

Опишу задачу, которая состоит в разработке схемы БД для
> хранения данных, поступающих извне.

Вот это - хорошо бы, потому что не понятно, чем вы там страдаете.
отчего сыр-бор.

Эти данные поставляются с
> фиксированной точностью. Точность предоставления данных регламентирована
> и вряд ли будет меняться. Вторая задача - использование этой БД в
> клиенте. Клиент - аналитическое приложение, которые строит разные модели
> на основе данных в БД. Алгоритмы расчета используют тип double. Стоит
> добавить, что этот клиент - не единственный. Возможны другие способы
> использования этой БД. Моя идея хранить данные в БД в виде numeric и
> выполнять преобразования на стороне клиента из numeric в double.

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

вы про сами данные-то расскажите, что там хранится-то у вас.
Сами данные-то какие ? Хотя бы пример поля типичного,
и что оно из себя представляет.

> Примеру буду очень рад. Вышлите мне, пожалуйста, на мой адрес, указанный
> в профайле (он открыт сейчас).

да

Posted via ActualForum NNTP Server 1.4

Пример "правильного" приложения, работающего с сервером через CTLib Open Client с использованием получения данных в native-форме, т.е. в такой, как данные хранятся в БД. (альтернативой было бы получение данных в текстовом виде).