Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 11   вперед  Ctrl      все
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
надо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю
с массивами напрямую.
причём здесь SQL...
18 май 06, 16:22    [2680015]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
SergSuper
Как уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111".


По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Имплементации мампса могут поддерживать (дополнительно) задание других соглашений, в частности строковой безотносительно содержания. В ней "2" пойдет после "111".

По умолчанию сортировка индексная.
USER>s a("2")=""
USER>s a("111")=""
USER>w
a(2)=""
a(111)=""
Если значения - числа то сравниваются как числа. Если не числа то сравниваются как строки по установленному для глобали / процесса коллейшена. Если сравнивается число и не число, то числа всегда меньше нечисел. Исключение - пустая строка, она сортируется перед числами.

SergSuper
Значит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя
Если я не прав то объясните как это решается

Имеется ввиду конечно использование индексного поиска


s i=2 f  s i=$o(a(i)) q:(i="")!'(111]]i)  w i,!
Начальное значение итератора 2. В цикле берем следующее значение индекса после итератора. Прекращаем цикл если итератор пуст (данные кончились) или если 111 не сортируется после итератора. В цикле пишем в текущий девайс значение индекса и перевод строки. Например:
USER>w
a(2)=""
a(3)=""
a(34)=""
a(111)=""

USER>s i=2 f  s i=$o(a(i)) q:(i="")!'(111]]i)  w i,!
3
34
18 май 06, 16:27    [2680048]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Sergei Obrastsov
надо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю
с массивами напрямую.
причём здесь SQL...

а причем тут "запросы типа i between 2 and 111 или просто i>2"?
впрочем ладно, может я просто неправильно воспринимаю.
но я все-равно ответил, числа отсортируются правильно.
18 май 06, 16:33    [2680096]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ну я
USER>s i=2 f s i=$o(a(i)) q:(i="")!'(111]]i) w i,!
3
34
[/src]

а зачем так мудрить "'(111]i)"? не проще написать i>111, все-равно ведь известно, что там числа? :)

С уважением. Сергей
18 май 06, 16:37    [2680133]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Sergei Obrastsov
ну я
USER>s i=2 f s i=$o(a(i)) q:(i="")!'(111]]i) w i,!
3
34
[/src]

а зачем так мудрить "'(111]i)"? не проще написать i>111, все-равно ведь известно, что там числа? :)

С уважением. Сергей

Инерция мышления. Привычка работать только с параметрами как таковыми.
Кстати, условие выхода i>111 пустит в цикл также и 111, то есть нужно i'<111.
18 май 06, 17:16    [2680394]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?
Если типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"?
18 май 06, 17:23    [2680443]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Т.е. если есть набор строк:
111
111-ый нах
2
2-ой нах
Вася
Петя
то в каком порядке все эти строки в кешовом "индексе" расположатся? В таком:
2
111
111-ый нах
2-ой нах
Вася
Петя
?
18 май 06, 17:37    [2680552]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?

Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.
Пьяный Лох
Если типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"?

Есть детальное описание (в стандарте) того, что называется каноническим представлением числа. Полное определение довольно длинное, не буду приводить. Например "2" это число, а "2.00" или "2." это уже строки. Речь идет именно о каноническом представлении чисел для индексной сортировки, ни о чем другом. Если работать с мампсом, то путаницы обычно ни у кого не возникает более одного раза ))).
Выяснить что из себя есть каноническое и неканоническое представление можно через операцию +: значение переменной str есть каноническое представление числа если +str=str. Исключения и нюансы - с плавающей точкой.
18 май 06, 17:48    [2680614]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
Т.е. если есть набор строк:
111
111-ый нах
2
2-ой нах
Вася
Петя
то в каком порядке все эти строки в кешовом "индексе" расположатся? В таком:
2
111
111-ый нах
2-ой нах
Вася
Петя
?

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

С уважением. Сергей
18 май 06, 17:52    [2680639]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 ну я
Пьяный Лох
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?

Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.

Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен?

-----------

2 Sergei Obrastsov
при числовой сортировке именно так. есть правда маленькая деталь,
а нафига совать в индекс разные логические типы данных?
там где нужны числа у меня будут числа, а там где строки - строки

Нафига? Не знаю... А нафига отсутствие типизации сделали? Значит это кому-нибудь нужно? Если это кому-нибудь нужно - наверное и работать с этим кому-нибудь приходится?

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

А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали).
18 май 06, 18:08    [2680755]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
2 ну я
Пьяный Лох
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?

Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.

Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен?

Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь. А про радость не могу ничего сказать - это нетехнический вопрос. Пока не вижу чего тут пугаться или радоваться - соглашение о правиле индексной сортировке на редкость практичное. Если бы в мампсе была типизация - то мы бы зашились с этими типами. Есть куча систем которые должны быть по своему устройству (как следствие их назначения) непрерывно изменяемы. В первую очередь бизнес-ориентированные. Если нам еще и типами заниматься - зашились бы точно.
18 май 06, 18:23    [2680833]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
Были бы типы данных - не было бы таких вопросов. Поле числового типа сортировалось бы как набор чисел, и строку туда нельзя было бы записать, а в поле строкового типа можно было бы записать любую строку (хоть бы даже и содержащую "каноническое представление числа"), и сортировалось бы это как набор строк.

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)
и зачем вот это "нельзя записать"? я сам строю БД и решаю куда что писать.


А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали).

можно пример такой необходимости, что-то я навскидку ничего представить
не могу?
ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются
на принцип "str=+str", как справедливо заметил "ну я".
только это не операция на уровне "послать запрос 2<i<111 и получить список"
это несколько другой уровень абстракции

С уважением. Сергей
18 май 06, 18:37    [2680900]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 ну я
Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь.

Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"?

Если бы в мампсе была типизация - то мы бы зашились с этими типами. Есть куча систем которые должны быть по своему устройству (как следствие их назначения) непрерывно изменяемы. В первую очередь бизнес-ориентированные. Если нам еще и типами заниматься - зашились бы точно.

Да ладно Вам. Я даже не буду спорить с тем, что иногда сильная типизация хуже, чем слабая (но только иногда, имхо). Речь не про то. Если уж система расчитана на слабую типизацию - кто мешает факт наличия этой самой слабой типизации унутре себя учесть? Хранили бы в месте со значением переменной еще один байт - "тип", не имели бы проблем с определением этого самого типа. Собственно предложенное решение ("при записи конкатенируешь с пробелом, при чтении пробел выкидываешь") и есть та самая информация о типе значения. Тока почему-то не на уровне системы, а ручками делать.
18 май 06, 18:39    [2680905]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 Sergei Obrastsov

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)

Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений.

можно пример такой необходимости, что-то я навскидку ничего представить не могу?

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

ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я".

Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа.
18 май 06, 18:51    [2680968]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
2 ну я
Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь.

Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"?

)))
Я, конечно, понимаю, что хочется повыделываться, но это неверное правило. Если вам придется работать с мампсом, вы сами себя переубедите, на простых контрольных примерах. А если не придется - то не берите в голову.
18 май 06, 18:54    [2680990]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
это неверное правило.

Тогда какое верное?
Не всем строкам пробел спереди приписывать? А каким?
18 май 06, 18:58    [2681006]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Если вам придется работать с мампсом

не дай бог :)
18 май 06, 18:58    [2681014]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
Это мумпсисты должны примеры приводить, когда необходимо в одном поле хранить разнотипные переменные. Все ж из их лагеря раздаются крики о том, что слабая типизация это хорошо, и без этого "зашились бы".

Гнать не нужно. Никто вам ничего не должен, не выдумывайте. И криков никаких нет и лагеря никакого нет.

Пьяный Лох
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.

А зачем это может понадобиться?
USER>w "111"+"111"
222
USER>w 111+"111"
222
USER>w "111"+111
222
USER>w 111
111
USER>w "111"
111
USER>w +"111"
111
Хотя мне известны способы как различить, но хотелось бы услышать законченную мысль: Не отличить строку от представления числа, что безусловно необходимо для ....
Вот для чего это необходимо, хотелось бы понять.
18 май 06, 19:04    [2681046]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
ну я
это неверное правило.

Тогда какое верное?
Не всем строкам пробел спереди приписывать? А каким?

Быстрый вопрос - проявление нежелания подумать даже немного.
18 май 06, 19:07    [2681062]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
2 Sergei Obrastsov

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)

Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений.

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


можно пример такой необходимости, что-то я навскидку ничего представить не могу?

Это мумпсисты должны примеры приводить, когда необходимо в одном поле хранить разнотипные переменные.

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


ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я".

Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа.

я прошу прощения, конечно, но я не вижу разницы между 111 и "111":
111+2=113
"111"+2=113
для чего оно мне понадобится? чтобы "строково сортировалось"? ну, я это
учту при выводе, раз уж так кому-то захотелось.
18 май 06, 19:10    [2681073]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
Пьяный Лох
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.

А зачем это может понадобиться?
USER>w "111"+"111"
222

А что, такого не может быть:
USER>w "111"+"111"
111111
USER>w "111"+111
111111
USER>w 111+"111"
111111
USER>w 111+111
222
???
18 май 06, 19:10    [2681074]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.
18 май 06, 19:14    [2681100]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
ну я
Пьяный Лох
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.

А зачем это может понадобиться?
USER>w "111"+"111"
222

А что, такого не может быть:
USER>w "111"+"111"
111111
USER>w "111"+111
111111
USER>w 111+"111"
111111
USER>w 111+111
222
???

Нет, первых три случая не может быть. Четвертый должен быть.
Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием.
18 май 06, 19:17    [2681110]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
Нет, первых три случая не может быть. Четвертый должен быть. Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием.

Ок. Это, видимо, вопрос синтаксиса.

Что вернется в результате такой операции:
USER>w "abc"+"def"
?
Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)?
Я, пардон, синтаксиса мумпса не знаю, потому и спрашиваю. Можно в какой-нибудь онлайн хелп послать, не обижусь.
18 май 06, 20:25    [2681265]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
Что вернется в результате такой операции:
USER>w "abc"+"def"
?
Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)?

+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0.
USER>w +"abc"
0
USER>w +"123abc"
123
USER>w +"123e3abc"
123000
USER>w +"123.98abc"
123.98
USER>w +"++--+-123"
-123
Документация ставится при установке, также есть онлайн
тынц
18 май 06, 21:12    [2681365]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить