ReSQL.ru
     
powered by simpleCommunicator - 2.0.18     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / SQLite [игнор отключен] [закрыт для гостей] / тонкости affinity type
12 сообщений из 12, страница 1 из 1
тонкости affinity type
    #40059936
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingiz
Участник
обсуждается как хранятся данные в различных полях
https://sqlite.org/datatype3.html#determination_of_column_affinityA column that uses INTEGER affinity behaves the same as a column with NUMERIC affinity. The difference between INTEGER and NUMERIC affinity is only evident in a CAST expression: The expression "CAST(4.0 AS INT)" returns an integer 4, whereas "CAST(4.0 AS NUMERIC)" leaves the value as a floating-point 4.0.

шото совершенно не понятна.
...
Рейтинг: 0 / 0
05.04.2021, 16:51
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059943
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingiz
Участник
автор4.2. Type Conversions Prior To Comparison

SQLite may attempt to convert values between the storage classes INTEGER, REAL, and/or TEXT before performing a comparison.

этот раздел тоже,



только что было написано, что

авторAn INTEGER or REAL value is less than any TEXT

зачем выполнять конвертацию в разделе 4.2?
...
Рейтинг: 0 / 0
05.04.2021, 17:08
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059959
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
tchingiz
обсуждается как хранятся данные в различных полях
https://sqlite.org/datatype3.html#determination_of_column_affinityA column that uses INTEGER affinity behaves the same as a column with NUMERIC affinity. The difference between INTEGER and NUMERIC affinity is only evident in a CAST expression: The expression "CAST(4.0 AS INT)" returns an integer 4, whereas "CAST(4.0 AS NUMERIC)" leaves the value as a floating-point 4.0.


шото совершенно не понятна.
Тут надо вспомнить что numeric это традиционный тип существующий в множестве БД, но реально отсутствующий в SQLite (в смысле как тип хранения отсутствует). Поэтому numeric работает как real на выдаче результата.
...
Рейтинг: 0 / 0
05.04.2021, 17:50
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059962
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Ты же книжку переводил 21709672 читай там "5.2.3 Классы памяти". Наверно правильнее назвать "типы данных"
...
Рейтинг: 0 / 0
05.04.2021, 17:52
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059970
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
tchingiz
автор4.2. Type Conversions Prior To Comparison

SQLite may attempt to convert values between the storage classes INTEGER, REAL, and/or TEXT before performing a comparison.

этот раздел тоже,



только что было написано, что

авторAn INTEGER or REAL value is less than any TEXT

зачем выполнять конвертацию в разделе 4.2?Не "выполнять" а "может выполнять".

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

Сравни 123 и "abc".
Подчиняясь стандартному алгоритму, мы должны превратить 123 (которая в базе лежит как одно-байтный integer) в текст "123" и потом сравнить его с текстом "abc". Так как буква "1" находится в стандартном ASCII (да и во всех известных страницах юникода) раньше чем "a" то "123" меньше чем "abc".
Но так как мы заранее знаем что значение в поле с типом хранения integer или real всегда будет превращаться в строку которая содержит только цифры и точки - она всегда будет идти раньше в алфавитной сортировке чем строка содержащая хотя бы одну букву.
Вывод, при сравнении 123 и "abc" достаточно сравнить типы и первое значение всегда будет меньше второго.

А вот если у нас 123 и 123.4 - тут у тебя есть одно-байтный integer и восьми-байтный real - прямое сравнение невозможно, поэтому первое значение будет сконвертировано в восьми-байтный real и потом уже сделано сравнение.
...
Рейтинг: 0 / 0
05.04.2021, 18:09
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059979
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingiz
Участник
Dima T
Ты же книжку переводил 21709672 читай там "5.2.3 Классы памяти". Наверно правильнее назвать "типы данных"

из того, что я читаю в доках

константы относятся к 'классам памяти' (этот термин можно использовать вперемежку
с термином 'тип данных'),
а, ат лист, поля в create table - имеют type affinity = близость к типу.
Про близость типу не было оговорки, что её можно путать с термином 'тип данных".
Разные аффинити по разному себя ведут, если в него (поле) вносить константы одного
класса памяти.

"32000.0" вносишь в поле "NUMERIC" - в таблице окажется short,
если "32000" вносишь в поле "REAL" - в таблице окажется, скорее всего, float

авторA column with REAL affinity behaves like a column with NUMERIC affinity except that it forces integer values into floating point representation.
...
Рейтинг: 0 / 0
05.04.2021, 18:30
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059984
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
tchingiz
из того, что я читаю в доках

константы относятся к 'классам памяти' (этот термин можно использовать вперемежку
с термином 'тип данных'),
а, ат лист, поля в create table - имеют type affinity = близость к типу.
Про близость типу не было оговорки, что её можно путать с термином 'тип данных".
Разные аффинити по разному себя ведут, если в него (поле) вносить константы одного
класса памяти.

"32000.0" вносишь в поле "NUMERIC" - в таблице окажется short,
если "32000" вносишь в поле "REAL" - в таблице окажется, скорее всего, float

авторA column with REAL affinity behaves like a column with NUMERIC affinity except that it forces integer values into floating point representation.
Верно, предрасположенность (affinity) нельзя путать с "типом данных".
Affinity это свойство парсера. В движок пришло "нечто" - определяем тип этого "нечто" - в таблице предполагается хранить это "нечто" как "что-то". Это возможно (вот здесь мы и смотрим на предрасположенность)? Если да, то "нечто" превращается в "что-то", если нет - плюем и оставляем "нечто" как "нечто".
...
Рейтинг: 0 / 0
05.04.2021, 18:54
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40059987
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
По существу, на affinity имеет смысл смотреть если у тебя в базе должно хранится одно, а посылаешь ты туда другое. И все собственно говоря. В остальных случаях оно совершенно прозрачно и для писателя данных и для читателя.

Например если у тебя есть какой-нибудь цифровой код в котором вполне легально иметь нули в начале и эти нули надо хранить, тогда делаешь
Код: sql
1.
2.
create table t (code text primary key, somedata integer);
insert into t values ("000123", "000123");

В первом поле у тебя нули сохраняться, потому что affinity при создании таблицы было определено как text, а во втором нули исчезнут, потому что affinity - int.
А если сделать
Код: sql
1.
2.
create table t (code primary key, somedata);
insert into t values ("000123", 123);

То мы получим на выходе тоже самое что и в предыдущем примере, но писатель сам следит за правильностью типов и affinity для обоих полей установлена в numeric.
...
Рейтинг: 0 / 0
05.04.2021, 19:08
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40060073
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingiz
Участник
White Owl

А вот если у нас 123 и 123.4 - тут у тебя есть одно-байтный integer и восьми-байтный real - прямое сравнение невозможно, поэтому первое значение будет сконвертировано в восьми-байтный real и потом уже сделано сравнение.



но меня это смущает
авторbetween the storage classes INTEGER, REAL, and/or TEXT before performing a comparison
а ты показал int и real
пысы
после работы еще перечитаю
...
Рейтинг: 0 / 0
06.04.2021, 10:33
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40060168
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
tchingiz
White Owl

А вот если у нас 123 и 123.4 - тут у тебя есть одно-байтный integer и восьми-байтный real - прямое сравнение невозможно, поэтому первое значение будет сконвертировано в восьми-байтный real и потом уже сделано сравнение.



но меня это смущает
авторbetween the storage classes INTEGER, REAL, and/or TEXT before performing a comparison

а ты показал int и real
пысы
после работы еще перечитаюНу да, забыл об одной ситуации: Если в поле с text affinity записан текст который на самом деле число.
Код: sql
1.
2.
3.
create table t (code text primary key, somedata integer);
insert into t values ("000123", "000123");
select code=somedata from t;

Результат - 1. То есть движок сделал конвертацию одного из операндов.

Подозреваю что code. Потому что text affinity на поле не означает в поле действительно текст. Вот было бы там text storage и numeric affinity - тогда можно сразу сказать что в поле натуральный текст который нельзя интерпретировать как число - и можно делать сравнение текста и числа без конвертации (я уже объяснял как). Но так как у поля text affinity - парсер туда кладет текст независимо от того похоже оно на число или нет. Так что при сравнении есть смысл сделать коневертацию одного из полей.
Хотя последнее это все мои догадки, в документации оно не расписано, а в код движка лезть лениво. Но лично я делал бы так.
...
Рейтинг: 0 / 0
06.04.2021, 15:11
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40061812
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingiz
Участник
White Owl,
сенкс
4.14.1. Sort Order

The results of a comparison depend on the storage classes of the operands, according to the following rules:

A value with storage class NULL is considered less than any other value (including another value with storage class NULL).

An INTEGER or REAL value is less than any TEXT or BLOB value. When an INTEGER or REAL is compared to another INTEGER or REAL, a numerical comparison is performed.

A TEXT value is less than a BLOB value. When two TEXT values are compared an appropriate collating sequence is used to determine the result.

When two BLOB values are compared, the result is determined using memcmp().



4.2Affinity is applied to operands of a comparison operator prior to the comparison according to the following rules in the order shown:

If one operand has INTEGER, REAL or NUMERIC affinity and the other operand has TEXT or BLOB or no affinity then NUMERIC affinity is applied to other operand.




целое меньше чем текст, но

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
create table t (code text primary key, v integer);
insert into t values ("000123", "000123");
insert into t values ("00019", "00020");
insert into t values ("000+9", "00020");
select code, v, code <= v from t;




select code, v, code <= v from t;

code    v    code <= v
------  ---  ---------
000123  123  1        
00019   20   1        
000+9   20   0
но в красном случае они равны - было преобразование текста к целому (4.2),
а в фиолетовом - текст меньше целого (4.1), хотя численные меньше текста (4.2)
в зеленом - не было преобразования и хотя
000+9 меньше чем 00019, 000+9 оказалось больше 20 согласно 4.1

--
транзитивность сравнения нарушена, ну ладно

"000+9" < "00019" и "00019" < 20 и при этом "000+9" > 20
...
Рейтинг: 0 / 0
12.04.2021, 18:32
| Ответить | Цитировать | Написать  
тонкости affinity type
    #40062057
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
tchingiz

транзитивность сравнения нарушена, ну ладно

"000+9" < "00019" и "00019" < 20 и при этом "000+9" > 20

Ни каких нарушений. "000+9" это чистый текст.
Никакой арифметики внутри поля не делается (и не предполагается делать). А как положительное число это тоже прочитать нельзя, потому что по правилам записи цифр знак всегда пишется слева от цифр а не вперемешку с ними.

"000+9" < "00019" - две строки, алфавитное сравнение.
"00019" < 20 - строка и число, строка лежит в text affinity поле - возможно это не строка, делаем конвертацию в число и сравниваем числа.
"000+9" > 20 - строка (которая действительно строка), всегда больше чем число.
...
Рейтинг: 0 / 0
13.04.2021, 14:23
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / SQLite [игнор отключен] [закрыт для гостей] / тонкости affinity type
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (1): Анонимы (1)
Читали форум (1): Анонимы (1)
Пользователи онлайн (11): Анонимы (8), Yandex Bot 1 мин., Google Bot 3 мин., Bing Bot 4 мин.
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
Start [/forum/topic.php?fid=54&tid=2008334]:
 0ms
get settings:
 0ms
get forum list:
 8ms
check forum access:
 0ms
check topic access:
 0ms
track hit:
 37ms
get topic data:
 7ms
get forum data:
 1ms
get page messages:
 13ms
update_topic_read_status (2008334): 13.04.2021 14:23:34:
 0ms
get tp. blocked users:
 0ms
get online users:
 25ms
check new:
 1ms
others: 85ms
total:  177ms
созд. / загр.: 177ms (нв.: 1ms)
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]