Переключение на Главную Страницу Страницы: 1 ... 6 7 [8] 9 10 ... 20 ОтправитьПечать
Очень популярная тема (более 25 ответов) 1sqlite (число прочтений - 64583 )
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #105 - 26. Октября 2007 :: 14:47
Печать  
orefkov

1. из вчерашнего осталось только

select * from Номенклатура
where parentid = '     0   '
and isfolder = 1
and descr > 'У'


дает пустой запрос, хотя
элементы, удовлетворяющие условию, есть


select * from Номенклатура
where parentid = '     0   '
and isfolder = 1
and descr < 'У'

"<", "!=", "-" - отрабатывает нормально.


select * from Номенклатура
where parentid = '     0   '
and isfolder = 1
and descr > 'У'
order by descr

отрабатывает нормально, но там совсем другой план выполнения


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

select Н1.descr, Н2.descr from Номенклатура Н1
left join Номенклатура Н2
on Н1.parentid = Н2.id


вот так - результат другой

select Н1.descr, Н2.descr from Номенклатура Н1
join Номенклатура Н2
on Н1.parentid = Н2.id


для обоих вариантов значения Н1.descr и Н2.descr одинаковые (это неверно)
в первом варианте выдает всего две строки


full join
right join

на том же тесте выдают пустой результат (==0) без объяснения причин.
Когда ты добавишь обработку ошибок, настанет праздник.

3. Для реквизита, по которому стоит галка "Отбор" (флажок, возможные значения 0 и 1)

select * from Номенклатура
where _фпНеВключатьВПрайс = 0

Все отлично, включая выбор индекса


select * from Номенклатура
where _фпНеВключатьВПрайс > 0

В результат попадают _все_ строки (условие не учитывается), хотя выбор индекса правильный

Условие "=1" ">1" выдают одинаковый результат, соответствующий "=1" (для ">1" должен быть пустой результат).

Условие "!=1" не учитывается (выдаются все строки), индекс не используется
Код
Выбрать все
6	Integer	1	0
7	Eq	355	50	collseq(BINARY)
 



4. (добавлено 10.27 0:22)

select * from Номенклатура
where parentid = '     0   '
and isfolder = 1
and descr < 'У'
order by descr

как оказалось, неверно отрабатывает
без упорядочивания дает 56 строк (похоже на правду), с упорядочиванием - только 7.
« Последняя редакция: 26. Октября 2007 :: 20:37 - kms »  

De quelle planète es-tu?
Наверх
 
IP записан
 
spock
1c++ developer
1c++ moderator
Отсутствует



Сообщений: 822
Местоположение: Новосибирск
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: 1sqlite
Ответ #106 - 26. Октября 2007 :: 15:47
Печать  
kms, расскажи про выводы?
Какие они у тебя?
  
Наверх
ICQ  
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #107 - 26. Октября 2007 :: 15:59
Печать  
spock писал(а) 26. Октября 2007 :: 15:47:
kms, расскажи про выводы?
Какие они у тебя?

Чето лениво уже на сегодня.

А ты чего заинтересовался?
Есть мысли по эффективному разделению функций ключа по позиционированию и сортировке?
  

De quelle planète es-tu?
Наверх
 
IP записан
 
spock
1c++ developer
1c++ moderator
Отсутствует



Сообщений: 822
Местоположение: Новосибирск
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: 1sqlite
Ответ #108 - 26. Октября 2007 :: 16:51
Печать  
kms писал(а) 26. Октября 2007 :: 15:59:
А ты чего заинтересовался?

Хотел тему развить.

Цитата:
Есть мысли по эффективному разделению функций ключа по позиционированию и сортировке?

Добавить поле id в индекс pdescr. Класс
  
Наверх
ICQ  
IP записан
 
Arta
1c++ power user
Отсутствует



Сообщений: 2537
Местоположение: Нижний Новгород
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: 1sqlite
Ответ #109 - 26. Октября 2007 :: 16:56
Печать  
Касаемо индексов - у меня в SQL - неограниченное кол-во индексов, делаю там, где они мне необходимы. Для этого надо было подправить одну процедуру на сервере. Описание этой махинации опубликовано на софтпоинте.

Почему так нельзя сделать на тех же dbf базах?
Запретить 1С-ке также проверять индексы, начинающиеся на определенные слова. у меня индексы типа TC_*** 1С-кой при старте не проверяются, соответственно ошибка не выдается.
  
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: 1sqlite
Ответ #110 - 26. Октября 2007 :: 19:20
Печать  
orefkov писал(а) 20. Октября 2007 :: 04:52:

Версия 1.0.0.5
Пофиксены баги, найденные kms'ом и другими.
Ускорена работа с индексами.
Просьба затестить.
Особенно условия в where, join.
Как реагирует на order by.



ert файл остался на работе, а в приложенном zip только dll
Нельзя тестовый файл выложить?
  
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #111 - 26. Октября 2007 :: 20:35
Печать  
kiruha писал(а) 26. Октября 2007 :: 19:20:
ert файл остался на работе, а в приложенном zip только dll
Нельзя тестовый файл выложить?

Почти оригинальный 1004
  

1sqlite_001.ert ( 31 KB | Загрузки )

De quelle planète es-tu?
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: 1sqlite
Ответ #112 - 27. Октября 2007 :: 11:15
Печать  
Цитата:
Вот kms понимает, о чем я говорю.
А индексы - они и в Африке индексы, что в SQL, что в DBF.
И работа с ними везде одинакова.

Не везде, а в MSSQL и DBF. А "везде" работа с индексами совсем не одинакова.

kms писал(а) 26. Октября 2007 :: 10:45:
Как обстоят дела для DBF - надо исследовать.

Не понял. Что конкретно надо исследовать? Вроде бы в DBF всегда используется максимум INDEX SEEK?

Вообще, DBase использует свои подходы и к нему нельзя подходить с мерками MSSQL (или, еще того хуже, даже без чтения документации), потому что можно проглядеть что-нибудь полезное и получить решение хуже, чем оно могло бы быть.
  
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #113 - 27. Октября 2007 :: 12:03
Печать  
Uzhast писал(а) 27. Октября 2007 :: 11:15:
Не понял. Что конкретно надо исследовать? Вроде бы в DBF всегда используется максимум INDEX SEEK?

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

1. Пусть у нас есть DBF таблица и ее индекс 'И1'
2. Допустим, нам известна некоторая точка привязки 'X1'.
Видимо, для DBF, это будет адрес заданной физической записи в таблице.
Неважно, как мы ее нашли, это ноу-хау, которое никто не должен знать.
3. Мы хотим выбрать N строк подряд по индексу 'И1', начиная с первой строки, большей X1 (в терминах индекса 'И1')

Проблема: оценить затраты на осуществление данной операции.
Видимо, для этого нам нужно понять алгоритм, по которому эта операция будет осуществляться.
  

De quelle planète es-tu?
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: 1sqlite
Ответ #114 - 27. Октября 2007 :: 12:12
Печать  
kms писал(а) 27. Октября 2007 :: 12:03:
Проблема: оценить затраты на осуществление данной операции.
Видимо, для этого нам нужно понять алгоритм, по которому эта операция будет осуществляться.

Алгоритм не хуже, чем INDEX SEEK. Естественно, чтобы позионироваться B-дереве индекса Фоксу нужно время, отличное от константы (о чем нам как о каком-то откровении поведал Злобный карл).

В большом журнале позиционирование по номеру+SKIP работает очень быстро. Так что эффективность подхода проверена на практике. Более того, этот подход используется уже столько лет, сколько используются xBase-подобные системы.

Может быть ситуация, когда одному значению индексного выражения соответствует несколько записей, но замедлением от такой ситуации можно пренебречь. Это уже проблемы программиста - пользователя провайдера. Если в таблице слишком много повторяющихся записей (с точки зрения индексного выражения), то использование в этой ситуации провайдера с данным индексным выражением - архитектурный просчет программиста - пользователя провайдера. Любой инструмент можно использовать неправильно и отвественность за это должен нести пользователь инструмента, а не его создатель.
  
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #115 - 27. Октября 2007 :: 12:31
Печать  
Uzhast
Т.е., если отбросить лирику, то описанный тобой алгоритм по затратам совпадает с тем, что описал orefkov в
http://www.1cpp.ru/forum/YaBB.pl?num=1192855975/79#79
Так?

Кстати, для меня осталось непонятным, как с помощью
Цитата:

SKIP   [nRecords]   [IN nWorkArea | cTableAlias]
If the table has a master controlling index tag or index file, SKIP moves the record pointer to the record determined by the index sequence.

можно перейти к следующей записи от конкретной физической точки X1 по конкретному индексу И1?
А как по другому индексу (скажем, И2)?

Я то тебе могу сразу сказать, что документацию на FoxPro вижу первый раз в жизни.
Так что эту часть протокола можно пропустить Улыбка
Но стало интересно.
  

De quelle planète es-tu?
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: 1sqlite
Ответ #116 - 27. Октября 2007 :: 12:44
Печать  
kms писал(а) 27. Октября 2007 :: 12:31:
Т.е., если отбросить лирику, то описанный тобой алгоритм по затратам совпадает с тем, что описал orefkov в
http://www.1cpp.ru/forum/YaBB.pl?num=1192855975/79#79

ВЕРОЯТНО, не будет СКАНИРОВАНИЯ, если есть несколько записей с одинаковым значением индексного выражения. В целом описанный алгоритм верен. И, если бы Злобный карл читал документацию, то понять его он мог бы еще в первом моем посте, когда я описывал работу с физическими номерами и SKIP. Блин, kms, извини, никак остановится не могу Печаль Пошел за успокоительным

kms писал(а) 27. Октября 2007 :: 12:31:
Кстати, для меня осталось непонятным, как с помощью
Цитата:

SKIP   [nRecords]   [IN nWorkArea | cTableAlias]
If the table has a master controlling index tag or index file, SKIP moves the record pointer to the record determined by the index sequence.

можно перейти к следующей записи от конкретной физической точки X1 по конкретному индексу И1?

Фокс находит позицию этой записи в B-дереве индекса. Соответственно, получение следующей записи в порядке упорядочивания индекса - тривиально.
kms писал(а) 27. Октября 2007 :: 12:31:
А как по другому индексу (скажем, И2)?

Сделать SET ORDER для И2. И тогда SKIP уже будет использовать этот индекс. Возможно, плохо, что у SKIP'а два режима работы ("сырой" и "индексированный"), что запутывает. Однако, так удобнее.

kms писал(а) 27. Октября 2007 :: 12:31:
Я то тебе могу сразу сказать, что документацию на FoxPro вижу первый раз в жизни.
Так что эту часть протокола можно пропустить Улыбка

Хорошо, пропускаю. Улыбка То, что не читал, это нормально. Все мы что-то да не читали, у всех лень Улыбка Или времени не хватает. Вот только мало кто, совершенно не читав документацию, берется с апломбом рассуждать о вопросах, о которых не имеет представления. Блин, опять поперло Печаль
  
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #117 - 27. Октября 2007 :: 12:50
Печать  
Uzhast

ОК, вот, кстати, тема, которая явилась началом дискуссии:
http://www.1cpp.ru/forum/YaBB.pl?num=1192855975/64#64

Цитата:
Если ты используешь индекс для упорядочивания, то перейти по физическому номеру записи невозможно.
Кроме как full-scan'ом.
Так-что возможный алгоритм мог бы быть такой (для случая выборки следующих строк) :
1. Делаем index seek по ключу.
2. Сканируем по индексу дальше, ища запись с нужным физическим номером.
3. Получаем следующие записи.

Здесь можно сразу было поймать на словах "full-scan", которые, конечно, не соответствуют действительности.
Т.е. соответствовать могут, но 99.9% не соответствуют, ибо скорее всего алгоритмы типа seek с нужными блокировками все же будут эффективнее.

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

Так безопасен ли алгоритм, в котором мы
1. Позиционируемся на строку по индексу И0
2. Вычисляем ключ К1 строки для индекса И1 и запоминаем физический адрес X1
3. Позиционируемся (допустим, seek) по ключу К1 по индексу И1
4. Проматываем строки по индексу И1, пока не достигнем адреса X1
5. Выбираем (и возвращаем) строки по индексу И1, после точки привязки X1

Вопрос:
A. Так ли работает твой провайдер?
Б. Безопасен ли алгоритм?

Учитываем, что речь идет о многозадачной многопользовательской среде.
  

De quelle planète es-tu?
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: 1sqlite
Ответ #118 - 27. Октября 2007 :: 13:04
Печать  
kms писал(а) 27. Октября 2007 :: 12:50:
Однако обсудить хотелось бы вот что:
Цитата:
Однако этот алгоритм неверен. Во-первых, ключ этой записи уже мог изменится.
(Другой юзер уже переименовал, удалил, перенес в другую группу)
В лучшем случае новый ключ записи больше старого, и рано или поздно, двигаясь
по индкесу, мы до нее дойдем. В худшем - новый ключ меньше, либо отсутствует.
В этом случае вообще ничего не найдем.

Так безопасен ли алгоритм, в котором мы
1. Позиционируемся на строку по индексу И0
2. Вычисляем ключ К1 строки для индекса И1 и запоминаем физический адрес X1
3. Позиционируемся (допустим, seek) по ключу К1 по индексу И1
4. Проматываем строки по индексу И1, пока не достигнем адреса X1
5. Выбираем (и возвращаем) строки по индексу И1, после точки привязки X1

Вопрос:
A. Так ли работает твой провайдер?
Б. Безопасен ли алгоритм?

Учитываем, что речь идет о многозадачной многопользовательской среде.

А. Примерно, так, но использует физ.номера записей.
Б. Алгоритм, ИМХО, вполне безопасен с оговорками:
1) Возможны некоторые небольшие отрицательные эффекты в ТП, если в конфигурации применяется удаление записей без контроля ссылочной целостности.
2) В случае изменения полей первой отображаемой в ТП записи таким образом, что меняется положение записи в упорядоченной последовательности, то провайдер сработает ПО ДРУГОМУ алгоритму, чем используется в ODBC-провайдере (и предлагается некоторыми товарищами). А именно, будут отображены записи, начиная с нового значения выражения упорядочивания. Я не считаю такое поведение ошибочным, хотя с определенной точки зрения это и можно посчитать ошибкой. С другой точки зрения подобное поведение даже более правильное (если более важным считать подход, когда первая видимая строка не меняется). Вообще, я считаю нехорошим явлением, что некоторые личности считают подход ODBC-провайдера единственно верным. Оба подхода могут быть полезны и вредны в различных условиях.

И, наконец, я не говорил, что такая реализация провайдера, как у меня, единственно верная. Так же я не говорил, что это окончательный вариант реализации. Я предпочитаю решать задачу итеративными методами, а не пытаться построить счастье сразу и навсегда. Потому что итеративный подход позволяет избежать в будущем кучи лишних переделок, потому что сразу позволяет увидеть проблемные места.
  
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: 1sqlite
Ответ #119 - 27. Октября 2007 :: 13:50
Печать  
Ну, вот, почти готово.
Для того, что окончательно понять стоимость разделения индексов поиска и сортировки, осталось добавить последний штрих.

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

Поясню.
Если SKIP действует с алгоритмом не хуже SEEK, значит он либо
1. может промахнуться мимо нужной физической записи, если за время выполнения SKIP запись будет изменена
2. на время операции накладывается табличная блокировка
=== edited === это я перегрелся, наверное. блокировки текущей записи должно хватить ===
3. Либо... это не SEEK Улыбка

Как бы это проверить?


P.S.
У меня на работе в шкафу всегда есть коньяк. Много. Нет, не покупаю. Улыбка
Сам у себя бываю редким гостем - лучше лишний раз буду трезвым, чем без машины.
Но для урегулирования различных рабочих споров штука абсолютно магическая. Улыбка
  

De quelle planète es-tu?
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: 1 ... 6 7 [8] 9 10 ... 20
ОтправитьПечать