FoxClub Forums > Visual Foxpro, Foxpro for DOS > Поиск по таблице ::

• Войти

Поиск по таблице
dfr Автор Сообщений: 254 Откуда: Барнаул Дата регистрации: 29.07.2005	dfr 08.08.22 09:31:54 По LOCATE ищет первую запись, по CONTINUE следующую(щие) (2, 3, 4, ...). А как мне найти например 150-ю? В цикл оборачивать (150 раз CONTINUE) или есть еще варианты? Порядок записей в исходной таблице изменять нельзя. Поиск идет по полному соответствию в одном поле.

dfr
Автор

Сообщений: 254
Откуда: Барнаул
Дата регистрации: 29.07.2005

dfr

08.08.22 09:31:54

По LOCATE ищет первую запись, по CONTINUE следующую(щие) (2, 3, 4, ...). А как мне найти например 150-ю?
В цикл оборачивать (150 раз CONTINUE) или есть еще варианты?

Порядок записей в исходной таблице изменять нельзя.
Поиск идет по полному соответствию в одном поле.

Re: Поиск по таблице
Аркадий Сообщений: 252 Откуда: Санкт-Петербург Дата регистрации: 30.11.2005	Аркадий 08.08.22 09:41:20 Выбери селектом 150 записей и перейди на последнюю.

Re: Поиск по таблице
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002	Burn 08.08.22 15:40:05 dfr Порядок записей в исходной таблице изменять нельзя. Привязываться к физическому порядку записей в таблице это неправильно. В общем случае хранилище данных не гарантирует постоянный порядок. Если порядок важен - добавьте поле с номером по порядку и ваши проблемы пропадут

Re: Поиск по таблице

Burn

Сообщений: 5643
Откуда: Днепр
Дата регистрации: 02.01.2002

Burn

08.08.22 15:40:05

dfr
Порядок записей в исходной таблице изменять нельзя.

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

Re: Поиск по таблице
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002	Burn 08.08.22 15:40:55 Аркадий Выбери селектом 150 записей и перейди на последнюю. SELECT не гарантирует сохранение порядка записей

Re: Поиск по таблице
Владимир Максимов Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 08.08.22 18:12:31 Опишите саму задачу, а не выбранный Вами способ решения. Команды поиска Locate или Seek изначально предназначены для поиска "первого попавшегося" (одного!) значения. Именно под это они "заточены" и оптимизированы. Продолжение поиска через Continue - это уже "заплатка". Предполагает, что "одинаковых" значений немного. Несколько штук. Поэтому заботится о быстродействии особо не нужно. "Порядок следования записей" - это также "виртуальное" понятие. Зависит от кучи разных условий. Тот же LOCATE будет учитывать текущий активный индекс, например. Т.е. как и упомянул Burn нужно какое-то поле (или набор полей), которое и будет определять этот самый "порядок следования". А есть еще фильтры, связи, много чего, что может нарушить "естественный" порядок следования в таблице Если задача разовая, то можно и в цикле (SCAN FOR .. ENDSCAN). Но раз попросили "помощи клуба", то, вероятно, такие поиски будут выполняться довольно часто. Поэтому нужно больше информации, чтобы сформировать более оптимальное решение. Откуда возникла сама постановка вопроса: Найти 150-ое значение в таблице, перебирая записи в определенном порядке?

Re: Поиск по таблице

Владимир Максимов

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

08.08.22 18:12:31

Опишите саму задачу, а не выбранный Вами способ решения.

Команды поиска Locate или Seek изначально предназначены для поиска "первого попавшегося" (одного!) значения. Именно под это они "заточены" и оптимизированы. Продолжение поиска через Continue - это уже "заплатка". Предполагает, что "одинаковых" значений немного. Несколько штук. Поэтому заботится о быстродействии особо не нужно.

"Порядок следования записей" - это также "виртуальное" понятие. Зависит от кучи разных условий. Тот же LOCATE будет учитывать текущий активный индекс, например. Т.е. как и упомянул Burn нужно какое-то поле (или набор полей), которое и будет определять этот самый "порядок следования". А есть еще фильтры, связи, много чего, что может нарушить "естественный" порядок следования в таблице

Если задача разовая, то можно и в цикле (SCAN FOR .. ENDSCAN). Но раз попросили "помощи клуба", то, вероятно, такие поиски будут выполняться довольно часто. Поэтому нужно больше информации, чтобы сформировать более оптимальное решение. Откуда возникла сама постановка вопроса: Найти 150-ое значение в таблице, перебирая записи в определенном порядке?

Re: Поиск по таблице
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006	leonid 08.08.22 18:19:24 select * from (select * from MyTable where ... order by ...) z where recno()=150

Re: Поиск по таблице
dfr Автор Сообщений: 254 Откуда: Барнаул Дата регистрации: 29.07.2005	dfr 09.08.22 04:21:42 Требуется повытаскивать некоторые значения из ответа сервера в формате JSON. Для этого, грубо говоря, "ключ"-"значение" из JSON раскидываются по двум полям курсора. Вложенные элементы (ключи) прописываются через точку. В ответе могут быть вложенные массивы (чаще всего). Собственно для этого и нужен поиск "ключа" по наименованию и номеру. "Порядок записей в исходной таблице изменять нельзя." - лишнее конечно. Пока сейчас создаю второй курсор с уникальными "ключами", на его основе нумерую "ключи" в основном курсоре, далее на нем строю индекс "ключ"+"номер", далее поиск по SEEK. Задача не разовая, постоянная, хотелось бы изначально менее тормознутый алгоритм. Пока на отладке, на боевом пока не могу протестировать.

Re: Поиск по таблице

dfr
Автор

Сообщений: 254
Откуда: Барнаул
Дата регистрации: 29.07.2005

dfr

09.08.22 04:21:42

Требуется повытаскивать некоторые значения из ответа сервера в формате JSON.
Для этого, грубо говоря, "ключ"-"значение" из JSON раскидываются по двум полям курсора.
Вложенные элементы (ключи) прописываются через точку.

В ответе могут быть вложенные массивы (чаще всего). Собственно для этого и нужен поиск "ключа" по наименованию и номеру.

"Порядок записей в исходной таблице изменять нельзя." - лишнее конечно.

Пока сейчас создаю второй курсор с уникальными "ключами", на его основе нумерую "ключи" в основном курсоре, далее на нем строю индекс "ключ"+"номер", далее поиск по SEEK.

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

Re: Поиск по таблице
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008	akvvohinc 09.08.22 04:30:28 dfr В цикл оборачивать (150 раз CONTINUE) или есть еще варианты? m.nopp = 150 1) SELECT * FROM ( SELECT RECNO() AS recno FROM <alias1> WHERE <condition> ) <alias2> ; WHERE RECNO()=m.nopp INTO CURSOR cursor1 GO cursor1.recno IN <alias1> 2) SET FILTER TO <condition> IN <alias> GO TOP IN <alias> SKIP (m.nopp-1) IN <alias> SET FILTER TO IN <alias> Исправлено 3 раз(а). Последнее : akvvohinc, 09.08.22 04:35

Re: Поиск по таблице

akvvohinc

Сообщений: 4212
Откуда: Москва
Дата регистрации: 11.11.2008

akvvohinc

09.08.22 04:30:28

dfr
В цикл оборачивать (150 раз CONTINUE) или есть еще варианты?


m.nopp = 150


SELECT * FROM ( SELECT RECNO() AS recno FROM <alias1> WHERE <condition> ) <alias2> ;
WHERE RECNO()=m.nopp INTO CURSOR cursor1
GO cursor1.recno IN <alias1>


SET FILTER TO <condition> IN <alias>
GO TOP IN <alias>
SKIP (m.nopp-1) IN <alias>
SET FILTER TO IN <alias>

Исправлено 3 раз(а). Последнее : akvvohinc, 09.08.22 04:35

Re: Поиск по таблице
Владимир Максимов Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 09.08.22 13:36:03 Я так понимаю, есть "ключ", которому соответствует "массив" значений и задача заключается в том, что надо вернуть для "ключа" элемент "массива" с указанным номером. Под "массивом" физически подразумеваются записи таблицы с тем же самым значением "ключа" Ну, тут, очевидно, что надо организовать нумерацию элементов массива в момент их записи в таблицу (дополнительное поле с порядковым номером). Ну, или сразу после. А дальше, просто напрямую обращаться по этому номеру, которое уже будет записано в соответствующем поле. Лично я бы сосредоточился не на алгоритме поиска ("ключ"+"номер" - вполне нормальный вариант), а на алгоритме формирования этого самого "порядкового номера". Скорее всего, именно здесь будут задержки. Кстати, а почему нельзя этот самый порядковый номер формировать в момент записи элемента массива? Тут ведь монопольный доступ. Можно банальный max()+1 использовать Т.е. структура таблицы примерно такая Key - значение ключа Value - значение элемента массива Num - порядковый номер элемента массива для текущего ключа Поиск по выражению SEEK(Key + str(Num)) (если есть индекс) или LOCATE FOR Key = ... AND Num = ...

Re: Поиск по таблице

Владимир Максимов

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

09.08.22 13:36:03

Я так понимаю, есть "ключ", которому соответствует "массив" значений и задача заключается в том, что надо вернуть для "ключа" элемент "массива" с указанным номером. Под "массивом" физически подразумеваются записи таблицы с тем же самым значением "ключа"

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

Лично я бы сосредоточился не на алгоритме поиска ("ключ"+"номер" - вполне нормальный вариант), а на алгоритме формирования этого самого "порядкового номера". Скорее всего, именно здесь будут задержки. Кстати, а почему нельзя этот самый порядковый номер формировать в момент записи элемента массива? Тут ведь монопольный доступ. Можно банальный max()+1 использовать

Т.е. структура таблицы примерно такая

Key - значение ключа
Value - значение элемента массива
Num - порядковый номер элемента массива для текущего ключа

Поиск по выражению SEEK(Key + str(Num)) (если есть индекс) или LOCATE FOR Key = ... AND Num = ...

Re: Поиск по таблице
dfr Автор Сообщений: 254 Откуда: Барнаул Дата регистрации: 29.07.2005	dfr 09.08.22 16:05:41 Владимир Максимов Под "массивом" физически подразумеваются записи таблицы с тем же самым значением "ключа" Нет, там массивы "ключ"-"значение". Ну это в принципе не так важно. Владимир Максимов Кстати, а почему нельзя этот самый порядковый номер формировать в момент записи элемента массива? Ну да, так конечно быстрее будет.

Re: Поиск по таблице

dfr
Автор

Сообщений: 254
Откуда: Барнаул
Дата регистрации: 29.07.2005

dfr

09.08.22 16:05:41

Владимир Максимов
Под "массивом" физически подразумеваются записи таблицы с тем же самым значением "ключа"

Нет, там массивы "ключ"-"значение". Ну это в принципе не так важно.

Владимир Максимов
Кстати, а почему нельзя этот самый порядковый номер формировать в момент записи элемента массива?

Ну да, так конечно быстрее будет.

Re: Поиск по таблице
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 09.08.22 19:27:33 () физический порядок записей в свободных таблицах есть и был всегда - это RECNO() [AS I], и не надо для этого добавлять новые поля в таблицу типа "I, автоинкрементный". О чем и напомнил Леонид, если я правильно понял...

Re: Поиск по таблице

of63

Сообщений: 25244
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

09.08.22 19:27:33

() физический порядок записей в свободных таблицах есть и был всегда - это RECNO() [AS I], и не надо для этого добавлять новые поля в таблицу типа "I, автоинкрементный". О чем и напомнил Леонид, если я правильно понял...

Re: Поиск по таблице
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 09.08.22 21:19:41 Burn dfr Порядок записей в исходной таблице изменять нельзя. Привязываться к физическому порядку записей в таблице это неправильно. В общем случае хранилище данных не гарантирует постоянный порядок. Если порядок важен - добавьте поле с номером по порядку и ваши проблемы пропадут "" Привязываться к физическому порядку записей в таблице это неправильно Это в теории неправильно, но... Физ.Порядок бывает важен. Это бывает в ... разных ситуациях. Есть RECNO(), чем не ID, соблюдающий физический порядок записей...

Re: Поиск по таблице

of63

Сообщений: 25244
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

09.08.22 21:19:41

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

"" Привязываться к физическому порядку записей в таблице это неправильно
Это в теории неправильно, но...

Физ.Порядок бывает важен. Это бывает в ... разных ситуациях. Есть RECNO(), чем не ID, соблюдающий физический порядок записей...

Re: Поиск по таблице
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002	Burn 10.08.22 07:59:26 of63 Физ.Порядок бывает важен. Это бывает в ... разных ситуациях А потом вы меняете хранилеще информации и сурпрайз - все летит к чертям. Я знаю - я такую логику переводил с DBF на MS SQL. Причем разработка была чужая и об этой подставе я даже не подозревал

Re: Поиск по таблице

Burn

Сообщений: 5643
Откуда: Днепр
Дата регистрации: 02.01.2002

Burn

10.08.22 07:59:26

of63
Физ.Порядок бывает важен. Это бывает в ... разных ситуациях

А потом вы меняете хранилеще информации и сурпрайз - все летит к чертям.
Я знаю - я такую логику переводил с DBF на MS SQL. Причем разработка была чужая и об этой подставе я даже не подозревал

Re: Поиск по таблице
Аркадий Сообщений: 252 Откуда: Санкт-Петербург Дата регистрации: 30.11.2005	Аркадий 10.08.22 09:24:40 Burn SELECT не гарантирует сохранение порядка записей Простите, что не упомянул наличие опции ORDER у SELECT, можно присовокупить её, если известен порядок записей.

Re: Поиск по таблице
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002	Burn 10.08.22 19:25:23 Аркадий не упомянул наличие опции ORDER у SELECT, можно присовокупить её, если известен порядок записей Если известен порядок записей то решение задачи тривиальное и не надо городить цикл

Re: Поиск по таблице
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008	akvvohinc 11.08.22 01:00:17 Burn А потом вы меняете хранилище информации и сурпрайз - все летит к чертям. Если я правильно понял, то здесь речь не идет об использовании номера записи как ключа - он просто обеспечивает нужный порядок для подсчета. И если даже скопировать такую таблицу, то номера записей могут измениться (если удаленные записи не копировать), но их относительный порядок останется прежним, то есть искомая 150-я запись останется той же, что и была в исходной таблице.

Re: Поиск по таблице

akvvohinc

Сообщений: 4212
Откуда: Москва
Дата регистрации: 11.11.2008

akvvohinc

11.08.22 01:00:17

Burn
А потом вы меняете хранилище информации и сурпрайз - все летит к чертям.

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

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

Re: Поиск по таблице
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008	of63 13.08.22 17:26:07 Burn Аркадий не упомянул наличие опции ORDER у SELECT, можно присовокупить её, если известен порядок записей Если известен порядок записей то решение задачи тривиальное и не надо городить цикл Порядок записей в "SQL-хранилище" в принципе не известен. В хранилище "DBF-таблица" он известен... Не понял претензии, не понял слова "цикл"... Это о чем?

Re: Поиск по таблице

of63

Сообщений: 25244
Откуда: Н.Новгород
Дата регистрации: 13.02.2008

of63

13.08.22 17:26:07

Burn
Аркадий
не упомянул наличие опции ORDER у SELECT, можно присовокупить её, если известен порядок записей
Если известен порядок записей то решение задачи тривиальное и не надо городить цикл

Порядок записей в "SQL-хранилище" в принципе не известен. В хранилище "DBF-таблица" он известен... Не понял претензии, не понял слова "цикл"... Это о чем?

:: Список Форумов•Список тем•Поиск•Войти

Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 29 PaulWist (Гостей: 28)