Поиск нужной записи

[samonenko]

День добрый. У сам еще лаймерок в навижене, поэтому вопрос мой скорее всего тупой.
Пусть есть таблица у которой есть поле дата. ЭТО ПОЛЕ НЕ ВХОДИТ НИ В ОДИН КЛЮЧ ТАБЛИЦЫ. Мне нужно найти запись с максимальной датой. Если бы это поле было ключевым, то можно все бы сделать просто - поставитьэтот ключ, а затем find('+'). А как быть тут? Очевидно что можно просто в лоб пробежаться по всем полям и найти максимальное. Это давольно просто. Просто меня интересует, нельзя ли это еще более просто сделать.

[randrews]

Если самому не добавить ключ (что нужно делать с пониманием дела, не всегда это "лучше"), то только перебором.
Да, кстати, не забывайте, что записей с максимальной датой может быть несколько.

[samonenko]

Ясно. То, что их много это не страшно. Мне главно найти эту максимльную дату. А аотом я отфильтрую по ней, и получу все записи с этой датой. Собственно я уже все сделал перебором. Спасибо.

[romeo]

Цитата:

Сообщение от сНЕЖНЫЙ_бес

Собственно я уже все сделал перебором. Спасибо.

Ну хорошо .. У тебя в таблице 10 записей и перебрать их не долго .. А если тебе в книге надо будет найти максимальное значение? Тоже будешь перебирать? Задача решается созданием нужного ключа (можно только нави, без скуля) и написанием одной строки кода.

[art06]

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

[grif]

Не думаю что будут прям какие-то замедления, если снять MaintainSQLIndex

[OntheJump]

Цитата:

Сообщение от grif

Не думаю что будут прям какие-то замедления, если снять MaintainSQLIndex

кстати, офтоп..почитал тут в хелпе про MaintainSQLIndex и MaintainSIFTIndex.. Если я все правильно понял, то:

1. MaintainSQLIndex ставим в No, если ключ используем редко, тогда и сортировать сможем и модификации в таблице не будут медленнее;

2. MaintainSIFTIndex ставим в No, если в каком-то случае очень удобно использовать FlowField-поле, но используется оно редко или на малых наборах данных При этом и рыбку съедим и косточкой не подавимся.

Коллеги, поправьте меня если что не так. Также было бы интересно выслушать ваши дополнения и, может быть, интересные случаи, где вы отключали эти феньки

[konrad_imported]

Цитата:

Сообщение от OntheJump

1. MaintainSQLIndex ставим в No, если ключ используем редко, тогда и сортировать сможем и модификации в таблице не будут медленнее;

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

Кстати, на мибузе интересную процедурку выкинули - чистка sift-индексов.
http://www.mibuso.com/dlinfo.asp?FileID=812

[OntheJump]

Цитата:

Сообщение от konrad

Ключ может использоваться как угодно часто, но только для сортировки. Работает быстро и хорошо.

А хелп пишет, что если MaintainSQLIndex = Yes, то сортировка будет быстрее:

Цитата:

If an index exists, sorting by the fields matching the index will be faster, but modifications to the table will be slower.

Выборки с ограничением - имеется ввиду фильтрация?

[konrad_imported]

Цитата:

Сообщение от OntheJump

А хелп пишет, что если MaintainSQLIndex = Yes, то сортировка будет быстрее:
Выборки с ограничением - имеется ввиду фильтрация?

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