Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 18 19 20 21 22 23 24 25 [26] 27   вперед  Ctrl
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10575
hvlad,

вроде всё нормально теперь

SQL> set sqlda_display on;
SQL> select cast(1 as numeric(19, 2)) as n from rdb$database;

INPUT message field count: 0

OUTPUT message field count: 1
01: sqltype: 32752 NUMERIC(38) scale: -2 subtype: 1 len: 16
: name: CAST alias: N
: table: owner:

N
=============================================
1.00

SQL> SET BIND OF NUMERIC(38) TO LEGACY;
SQL> select cast(1 as numeric(19, 2)) as n from rdb$database;

INPUT message field count: 0

OUTPUT message field count: 1
01: sqltype: 580 INT64 scale: -2 subtype: 1 len: 8
: name: CAST alias: N
: table: owner:

N
=====================
1.00

SQL> select cast(1 as numeric(18, 2)) * cast(1 as numeric(18, 2)) as n from rdb$database;

INPUT message field count: 0

OUTPUT message field count: 1
01: sqltype: 580 INT64 scale: -4 subtype: 1 len: 8
: name: MULTIPLY alias: N
: table: owner:

N
=====================
1.0000

SQL>
20 июн 20, 10:57    [22154162]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
hvlad
Member

Откуда:
Сообщений: 10961
Симонов Денис
вроде всё нормально теперь
Спасибо
20 июн 20, 12:50    [22154200]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1379
hvlad,

Проверил - теперь для SUM двух полей - 18.2.
SUM(AMOUNT_TOTAL) - по-прежнему выдавало NUMERIC(38.2). Вылечилось ALTER'ом этого поля.

Но осталась проблема с суммой с числом:
CREATE TABLE TEST_TABLE (
    QUANTITY  INTEGER
);


SELECT
    SUM(QUANTITY)
FROM
    TEST_TABLE

"SUM BIGINT"

SELECT
    SUM(1 + QUANTITY)
FROM
    TEST_TABLE

"SUM NUMERIC(38,0)"
22 июн 20, 02:52    [22154850]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1379
И мое личное мнение по поводу INT128. Это замечательно, что разработчики FB реализовали новый тип данных для больших чисел (целых и дробных). Но я не понимаю, зачем надо было настолько серьезно переделывать реализацию работы с данными. Со сменой типа с INTEGER -> BIGINT у COUNT(*) в случае FB 3 понятно - таблицы легко могут содержать более 4 млрд строк. Но вот сейчас. Мало того, что в Delphi нет поддержки INT128 (ладно, это проблемы прикладников), так еще и старое поведение объявлено как LEGACY и требуется дополнительная манипуляция с сервером для получения классического поведения сервера. Может так в SQL-стандарте требуется, но я бы оставил преобразование типов, как в FB3, а включение новых типов сделал бы через настройку. Баз данных, которым требуются вместимость NUMERIC(38), несравнимо меньше, чем те, которым NUMERIC(18) хватит с запасом от слова навсегда.
22 июн 20, 03:11    [22154852]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10575
CyberMax,

да чего ты докопался до INT128. Это детали реализации. В других СУБД тоже есть типы с повышенной точностью, и в Delphi с ними умудряются как-то работать. Так что тут либо пилить компоненты доступа пилить, либо пользоваться режимом совместимости.

В общем-то int128 в FB определён как

struct FB_I128_t {
	ISC_UINT64 fb_data[2];
};

typedef struct FB_I128_t FB_I128;


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

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

interface Int128 : Versioned
{
	const uint STRING_SIZE = 46;	// includes terminating \0
	void toString(Status status, const FB_I128* from, int scale, uint bufferLength, string buffer);
	void fromString(Status status, int scale, const string from, FB_I128* to);
}


CyberMax

SELECT
    SUM(QUANTITY)
FROM
    TEST_TABLE

"SUM BIGINT"

SELECT
    SUM(1 + QUANTITY)
FROM
    TEST_TABLE

"SUM NUMERIC(38,0)"


и это правильно. Агрегатные функции должны расширять тип, иначе высока вероятность переполнения.
22 июн 20, 10:15    [22154962]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
hvlad
Member

Откуда:
Сообщений: 10961
CyberMax
Но я не понимаю, зачем надо было настолько серьезно переделывать реализацию работы с данными.
На самом деле там нет специальной переделки.
SUM использует ближайший бОльший тип по отношению к своему выражению - чтобы ничего не терять.
Я не уверен, что это всегда хорошо, но пока моё мнение не было поддержано.


CyberMax
Мало того, что в Delphi нет поддержки INT128 (ладно, это проблемы прикладников)
Насколько я понимаю, автор IBX под Lasarus (Tony Whyman) этим занимается, скорее всего этот тип будет отображён на BCD


CyberMax
включение новых типов сделал бы через настройку. Баз данных, которым требуются вместимость NUMERIC(38), несравнимо меньше, чем те, которым NUMERIC(18) хватит с запасом от слова навсегда.
Ты забываешь про повышенную точность промежуточных вычислений, когда 18 знаков не хватает (не все они должны быть перед запятой).
Особенно из-за наших (IB-шных) правил выведения типов для арифм. выражений.
22 июн 20, 10:28    [22154967]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Gallemar
Member

Откуда: г.Иркутск
Сообщений: 5328
А как с Fib+? Он очень популярен, а допиливать до четверки пока некому.
22 июн 20, 10:31    [22154972]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10575
Gallemar,

в чём проблема самому допилить? Или подождать пока это сделают в других компонентах, например IBX2 и тупо портировать код.
22 июн 20, 10:34    [22154976]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3284
Gallemar, с учётом текущих тенденций и увеличения доли GNUC'а, гораздо более интересным мне представляется создание максимально удобной обёртки fbclient под wxWidgets, QT, GTK+ (Glade) или же под упрощённое использование с STL.
22 июн 20, 10:38    [22154980]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Gallemar
Member

Откуда: г.Иркутск
Сообщений: 5328
Симонов Денис
Gallemar,

в чём проблема самому допилить? Или подождать пока это сделают в других компонентах, например IBX2 и тупо портировать код.

Ты меня переоцениваешь как программиста. Одно дело службы для обработки данных писать, другое - компоненты доступа. Про ibx уже думал, на сайте писали, что они как раз поддержкой четверки заняты. Ты pdo php для четверки будешь дописывать?
22 июн 20, 10:40    [22154981]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10575
rdb_dev,

под QT уже давно существует драйвер. Правда я понятия не имею насколько он поддерживает последние фичи FB
22 июн 20, 10:41    [22154982]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10575
Gallemar,

Gallemar
Ты pdo php для четверки будешь дописывать?


в принципе могу. Один фиг у них все новые типы будут только на string отображаться.

И кстати для Дельфи допилить драйвер намного проще. PHP написан на чистом C, поэтому использовать напрямую интерфейсы С++ из нового API не так легко. Я правда видел у них куски кода на плюсах в отдельных модулях, но это в виде исключения. Не уверен что они такие врезки в стандартную сборку будут включать.
22 июн 20, 10:50    [22154989]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
hvlad
Member

Откуда:
Сообщений: 10961
Gallemar
А как с Fib+?
А ты кого спрашиваешь ? :)
22 июн 20, 10:50    [22154991]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
hvlad
Member

Откуда:
Сообщений: 10961
Симонов Денис
PHP написан на чистом C, поэтому использовать напрямую интерфейсы С++ из нового API не так легко.
cloop генерит и обертки для C, но не думаю что их кто-то когда-то пробовал использовать :)
22 июн 20, 10:51    [22154992]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Gallemar
Member

Откуда: г.Иркутск
Сообщений: 5328
hvlad
Gallemar
А как с Fib+?
А ты кого спрашиваешь ? :)

Обчество :)
22 июн 20, 10:54    [22154994]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Dimitry Sibiryakov
Member

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

Симонов Денис
под QT уже давно существует драйвер. Правда я понятия не имею насколько он поддерживает
последние фичи FB

Вне зависимости от "последнести" фич этот драйвер - совершенно бесполезная фигня. Как и
вся DB часть Qt.

Posted via ActualForum NNTP Server 1.5

22 июн 20, 13:34    [22155118]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10575
Dimitry Sibiryakov,

я его не щупал, ничего сказать не могу, но точно знаю что он есть
22 июн 20, 13:46    [22155128]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3284
Давно хотел спросить разработчиков - как расшифровывается аббревиатура "jrd"?
22 июн 20, 14:05    [22155140]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
peter64
Member

Откуда:
Сообщений: 127
rdb_dev,
вроде так (хотя я и не разработчик)
jrd - jim relational database, .gdb - groton database.
Пусть поправят знающие.
22 июн 20, 14:10    [22155144]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28886
peter64,

всё верно.
gds - groton database systems.
http://www.ibase.ru/history/
22 июн 20, 14:13    [22155148]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3284
kdv, peter64,
Понятно, спасибо!
22 июн 20, 14:18    [22155156]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1379
Симонов Денис
да чего ты докопался до INT128.

Потому что мне на ровном месте сломали возможность работы с БД.

Симонов Денис
и это правильно. Агрегатные функции должны расширять тип, иначе высока вероятность переполнения.

Денис, я с тобой не согласен. в случае "SUM(QUANTITY)", "SUM(1 + QUANTITY)" и "SUM(0 + QUANTITY)" вероятность переполнения одинакова. Тем не менее, во втором и третьем случае я получаю NUMERIC(38). Да даже если будет переполнение, я могу самостоятельно указать серверу, какой тип использовать.
Добавлю, что много лет тому назад (во времена FB1.5 вроде ещё) использовал NUMERIC(9,2) для сумм и как-то раз получив overflow при выполнении SUM, просто поменял на NUMERIC(18.2). С тех пор не имею никаких проблем с переполнением.

Проверил на FB3 - SUM(SMALLINT), SUM(INTEGER), SUM(BIGINT) даёт BIGINT. По-большому счету, это все прозрачно для пользователя. Прочитав ответ Влада - понял, что произошло. Появился INT128 и сервер стал так же, как и раньше, приводить все к типу с наибольшей вместимостью. Но тут прикол в том, что мне не нужен INT128 от слова совсем. Не потому, что компонента доступа не поддерживает его (это отчасти), а потому, что избыточен. Если в FB 5 или в FB 6 введут INT256 или INT1024, мне он так же не понадобится. Я хочу задать верхнюю планку преобразования в INT64 и не заморачиваться, что когда-нибудь сервер вернет мне INT512 или что-то подобное. Когда он мне станет нужен, я сообщу об этом серверу.
Поэтому хочу, чтобы SET BIND OF NUMERIC(38) TO LEGACY работал для всех чисел, а не только для определенных случаев. У меня по-прежнему половина запроса возвращает NUMERIC(38).
P.S. Кстати, COUNT(*) возвращает BIGINT, а не INT128, что нелогично.
23 июн 20, 04:05    [22155622]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10281
CyberMax
P.S. Кстати, COUNT(*) возвращает BIGINT, а не INT128, что нелогично.
Как раз это - логично.
23 июн 20, 06:08    [22155638]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6913
Basil A. Sidorov
CyberMax
P.S. Кстати, COUNT(*) возвращает BIGINT, а не INT128, что нелогично.
Как раз это - логично.

не очень логично, на самом деле :-) Если номер записи 64-битный это еще не значит, что нельзя искусственно (джойнами, юнионами и т.п) сгенерить больше 2^64 выходных строк. И счетчик опять завернется, как это было в 2.5 при INT. Просто вероятность этого в реальной жизни слишком мала, чтобы менять COUNT еще раз.
23 июн 20, 08:44    [22155687]     Ответить | Цитировать Сообщить модератору
 Re: А что проект Devrace(FIBPlus) уже умер??  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10281
dimitr
не очень логично, на самом деле :-) Если номер записи 64-битный это еще не значит, что нельзя искусственно (джойнами, юнионами и т.п) сгенерить больше 2^64 выходных строк.
И сколько веков будет происходить генерация такого объёма данных? Сравнимо с кембрийской эрой или в кайнозой уложимся?
23 июн 20, 09:03    [22155698]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 18 19 20 21 22 23 24 25 [26] 27   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить