Поиск по таблице | |
---|---|
dfr Автор Сообщений: 254 Откуда: Барнаул Дата регистрации: 29.07.2005 |
По LOCATE ищет первую запись, по CONTINUE следующую(щие) (2, 3, 4, ...). А как мне найти например 150-ю?
В цикл оборачивать (150 раз CONTINUE) или есть еще варианты? Порядок записей в исходной таблице изменять нельзя. Поиск идет по полному соответствию в одном поле. |
Re: Поиск по таблице | |
---|---|
Аркадий Сообщений: 252 Откуда: Санкт-Петербург Дата регистрации: 30.11.2005 |
Выбери селектом 150 записей и перейди на последнюю.
|
Re: Поиск по таблице | |
---|---|
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002 |
Привязываться к физическому порядку записей в таблице это неправильно. В общем случае хранилище данных не гарантирует постоянный порядок. Если порядок важен - добавьте поле с номером по порядку и ваши проблемы пропадут |
Re: Поиск по таблице | |
---|---|
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002 |
SELECT не гарантирует сохранение порядка записей |
Re: Поиск по таблице | |
---|---|
Владимир Максимов Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000 |
Опишите саму задачу, а не выбранный Вами способ решения.
Команды поиска Locate или Seek изначально предназначены для поиска "первого попавшегося" (одного!) значения. Именно под это они "заточены" и оптимизированы. Продолжение поиска через Continue - это уже "заплатка". Предполагает, что "одинаковых" значений немного. Несколько штук. Поэтому заботится о быстродействии особо не нужно. "Порядок следования записей" - это также "виртуальное" понятие. Зависит от кучи разных условий. Тот же LOCATE будет учитывать текущий активный индекс, например. Т.е. как и упомянул Burn нужно какое-то поле (или набор полей), которое и будет определять этот самый "порядок следования". А есть еще фильтры, связи, много чего, что может нарушить "естественный" порядок следования в таблице Если задача разовая, то можно и в цикле (SCAN FOR .. ENDSCAN). Но раз попросили "помощи клуба", то, вероятно, такие поиски будут выполняться довольно часто. Поэтому нужно больше информации, чтобы сформировать более оптимальное решение. Откуда возникла сама постановка вопроса: Найти 150-ое значение в таблице, перебирая записи в определенном порядке? |
Re: Поиск по таблице | |
---|---|
leonid Сообщений: 3204 Откуда: Рига Дата регистрации: 03.02.2006 |
|
Re: Поиск по таблице | |
---|---|
dfr Автор Сообщений: 254 Откуда: Барнаул Дата регистрации: 29.07.2005 |
Требуется повытаскивать некоторые значения из ответа сервера в формате JSON.
Для этого, грубо говоря, "ключ"-"значение" из JSON раскидываются по двум полям курсора. Вложенные элементы (ключи) прописываются через точку. В ответе могут быть вложенные массивы (чаще всего). Собственно для этого и нужен поиск "ключа" по наименованию и номеру. "Порядок записей в исходной таблице изменять нельзя." - лишнее конечно. Пока сейчас создаю второй курсор с уникальными "ключами", на его основе нумерую "ключи" в основном курсоре, далее на нем строю индекс "ключ"+"номер", далее поиск по SEEK. Задача не разовая, постоянная, хотелось бы изначально менее тормознутый алгоритм. Пока на отладке, на боевом пока не могу протестировать. |
Re: Поиск по таблице | |
---|---|
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008 |
Исправлено 3 раз(а). Последнее : akvvohinc, 09.08.22 04:35 |
Re: Поиск по таблице | |
---|---|
Владимир Максимов Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000 |
Я так понимаю, есть "ключ", которому соответствует "массив" значений и задача заключается в том, что надо вернуть для "ключа" элемент "массива" с указанным номером. Под "массивом" физически подразумеваются записи таблицы с тем же самым значением "ключа"
Ну, тут, очевидно, что надо организовать нумерацию элементов массива в момент их записи в таблицу (дополнительное поле с порядковым номером). Ну, или сразу после. А дальше, просто напрямую обращаться по этому номеру, которое уже будет записано в соответствующем поле. Лично я бы сосредоточился не на алгоритме поиска ("ключ"+"номер" - вполне нормальный вариант), а на алгоритме формирования этого самого "порядкового номера". Скорее всего, именно здесь будут задержки. Кстати, а почему нельзя этот самый порядковый номер формировать в момент записи элемента массива? Тут ведь монопольный доступ. Можно банальный max()+1 использовать Т.е. структура таблицы примерно такая Key - значение ключа Value - значение элемента массива Num - порядковый номер элемента массива для текущего ключа Поиск по выражению SEEK(Key + str(Num)) (если есть индекс) или LOCATE FOR Key = ... AND Num = ... |
Re: Поиск по таблице | |
---|---|
dfr Автор Сообщений: 254 Откуда: Барнаул Дата регистрации: 29.07.2005 |
Нет, там массивы "ключ"-"значение". Ну это в принципе не так важно.
Ну да, так конечно быстрее будет. |
Re: Поиск по таблице | |
---|---|
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
() физический порядок записей в свободных таблицах есть и был всегда - это RECNO() [AS I], и не надо для этого добавлять новые поля в таблицу типа "I, автоинкрементный". О чем и напомнил Леонид, если я правильно понял...
|
Re: Поиск по таблице | |
---|---|
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
"" Привязываться к физическому порядку записей в таблице это неправильно Это в теории неправильно, но... Физ.Порядок бывает важен. Это бывает в ... разных ситуациях. Есть RECNO(), чем не ID, соблюдающий физический порядок записей... |
Re: Поиск по таблице | |
---|---|
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002 |
А потом вы меняете хранилеще информации и сурпрайз - все летит к чертям. Я знаю - я такую логику переводил с DBF на MS SQL. Причем разработка была чужая и об этой подставе я даже не подозревал |
Re: Поиск по таблице | |
---|---|
Аркадий Сообщений: 252 Откуда: Санкт-Петербург Дата регистрации: 30.11.2005 |
Простите, что не упомянул наличие опции ORDER у SELECT, можно присовокупить её, если известен порядок записей. |
Re: Поиск по таблице | |
---|---|
Burn Сообщений: 5643 Откуда: Днепр Дата регистрации: 02.01.2002 |
Если известен порядок записей то решение задачи тривиальное и не надо городить цикл |
Re: Поиск по таблице | |
---|---|
akvvohinc Сообщений: 4212 Откуда: Москва Дата регистрации: 11.11.2008 |
Если я правильно понял, то здесь речь не идет об использовании номера записи как ключа - он просто обеспечивает нужный порядок для подсчета. И если даже скопировать такую таблицу, то номера записей могут измениться (если удаленные записи не копировать), но их относительный порядок останется прежним, то есть искомая 150-я запись останется той же, что и была в исходной таблице. |
Re: Поиск по таблице | |
---|---|
of63 Сообщений: 25244 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Порядок записей в "SQL-хранилище" в принципе не известен. В хранилище "DBF-таблица" он известен... Не понял претензии, не понял слова "цикл"... Это о чем? |
© 2000-2024 Fox Club  |