Добрый день.
Предположим есть справочник Х. В нем n элементов.
Есть запрос к справочнику:
"Выбрать Первые 1 ссылка из Справочник.Х"
Внимание вопрос:
Всегда ли в результате выполнения запроса будет возвращен один и тот же элемент?

Не гарантируется

Если сортировка не указана, то не обязательно.

Безумие - это точное повторение одного и того же действия, раз за разом, в надежде на изменение.

(2) Если не указана, то подрубается рандомная сортировка или всё таки есть какая-то сортировка по-умолчанию?

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

(4) Нет. Никакого умолчания нет. Есть надежда (но это глупое чувство), что будет в порядке кластерного индекса. На надеяться на неё...

(6) (5) Есть же алгоритм вычисления этого "любого", вы же не верите в реальный компьютерный рандом или свободу воли ИИ?

Коллеги, аргументируйте свое мнение.

(8) 1С об этом говорит. Ссылку сейчас не найду, емнип, на ИТС можно почитать.

Мы говорим о клиент-серверной архитектуре.
В данном случае имеет смысл прислушаться не только к мнению 1С, но и к мнению разработчика СУБД.
В моем случае SQL. Что MS говорит по этому поводу?

(7) это уже зависит от SQL, а он может оценить наличие записей в кэше и выбрать ближайшую из кеша

(11) А если файловая?

(10) MS говорит так: если сортировка не указана в запросе, то порядок записей не гарантируется

(12) На файловых нормальные люди не работают.

(8) Это не мнение, это знание, подчерпнутое из докмеентации

(10) МС говоорит то же самое. Порядок не определен

(13) Нормальные люди не выбирают первый попавшийся элемент справочника

(16) Конечно же выбирают, когда подразумевается что он один

(16) бывает, для определения типа, например

(17) Тогда результат всегда будет одинаковый

(18)
неа. для определения типа - ПЕРВЫЕ 0

(19) Всегда может появиться новый элемент справочника. Например, изначально подразумевается, что договор у контрагента всегда один и поэтому везде в алгоритмах закладывается "выбрать первый попавшийся".

+(20)
для определения существования хотя бы одной записи - ПЕРВЫЕ 1

(16) Для проверки - есть ли там вообще хоть что-то. Зачем выбирать все? Достаточно любого первого.

История из жизни.
Давным давно я написал запрос к регистру данныеПроизводственныхКалендарей. Для получения какой то даты в рабочих днях.
Он больше года работал как часы.
Потом базу перезалил из ДТ и результат сломался. Оказалось порядок возвращаемых строк стал другой.
Была добавлена сортировка в текст запроса явно и снова стало все хорошо.

(0) Практика показывает, что не всегда.

(0) Нет гарантий, что возвращаться будет одно и то же значение.

(21) >> изначально подразумевается, что договор у контрагента всегда один и поэтому везде в алгоритмах закладывается "выбрать первый попавшийся".

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

(18) >> для определения типа, например.

Для определения типа не важно - какое именно значение получено (какой конкретно элемент попал в выборку). Автору ветки критично получить конкретный элемент.

(27) Не косяк, а именно так и задумано

(22) >> для определения существования хотя бы одной записи.

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

(7)(8) если сортировка не указана явно, то порядок никто не гарантирует.
этого уже должно быть достаточно, чтобы не задавать такие глупые вопросы.

(29) Плохо значит задумано. Если договор всегда один, то нафига справочник?
А если уж запилили справочник, то разработчик должен был подумать о том, что ни что не вечно под луной и там, где есть один договор, рано или поздно с вероятностью 99.9% появится и второй, и третий, и т.д.

(21) >изначально подразумевается, что договор у контрагента всегда один
Кем подразумевается? это в техДокументации? что за ересь?

(32) "разработчик должен был подумать о том" // От таких обобщающих дум проекты не делаются

(33) Бизнесом / постановщиком / кем-нибудь еще в цепи до разработчика

(33) А почему бы и нет? Сплошь и рядом постановщики формулируют свои хотелки в такой форме. Мамой клянутся, что *ля будут, но всегда только один договор.

(36) Когда мамой клянутся - 100% через неделю будет как минимум одно исключение из правил. Это наблюдение у меня работает в 100% случаев

(37) чем больше уверяют в невозможности события, тем раньше оно произойдет

(34) Не понял твоей мысли.

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

Ответ просили дать на простой вопрос :

// Всегда ли в результате выполнения запроса будет возвращен один и тот же элемент?

Ответ - не всегда. В базе возможны действия, которые изменяют результаты запросов.
И не важно, сколько запрашивается записей - одна или несколько - результаты запросов изменяются если с базой происходят какие-то изменения.

(39) Обобщать требования, думать наперед и делать непрошенные проверки - корень многих бед. Например, отодвигание даты выката очередного релиза.

(39) Ну вот бизнес и постановщик решили, что подумают об этом потом - если возникнет - а пока брать первый попавшийся

(41) Ну естественно, что всё должно быть в разумных пределах (думать наперед и делать непрошенные проверки).
Но в данном конкретном примере, ИМХО, разработчик просто обязан такие вещи предусматривать.

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

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

(0) Теоретически - нет, практически - да.

(46) и практически нет. Это приходит с опытом.

Тьфу, (45) было к (0)

Хотя... При наличии кластерного индекса в mssql... Возможно, что результат будет повторяемый всегда, тут не уверен. Но MS это в любом случае это официально не гарантирует. А следовательно даже если неявная сортировка в каких-то случаях и существует, то полагаться на недокументированные фичи как минимум непрофессионально.

(44) "Запрос должен гарантированно вернуть один единственный элемент и не просто один, а всегда один и тот же" // В сценарии появления новых элементов в справочнике задача в общем случае не решается

(49) Если выполнение запроса использует кластерный индекс, то конечно порядок будет всегда один и тот же. Но и тут только до первого перестроения индекса (пришла какая-нибудь ссылка по обмену с левым непоследовательным УИДом и привет).
Но он не всегда может использоваться.

(44) Ну допустим тебе поставили задачу: Создать новый регистр накопления, сумму для него взять из Документов вида ХХХ, как-то там обработать и записать в этот новый Регистр с привязкой к Договору. При этом мамой клянутся, что у каждого Контрагента лишь один договор и всю сумму надо сажать именно на него. Делов там на полчаса-час.
И тут разработчик такой - нет, я вам не верю, надо учесть, что договоров может быть много и надо кроме простейшей обработки ранее написать еще и блок распределения этих сумм по Договорам, причем с вариантами: 1) делить суммы между договорами пропорционально; 2) делать аналитический выбор, при помощи нейросети, на какой договор сажать и 3) с интерфейсом для Ответственных, чтобы суммы люди сами раскидывали.
Так что-ли?

(51) Кластерный индекс по полю ускоряет сортировку по этому полю, если она указана в запросе. Если в запросе нет указания на сортировку, то физический порядок записей в таблице (т.е. кластерный индекс) может игнорироваться. Там же сложные деревья. Зачем СУБД читать эти деревья, если сказано "первый попавшийся"? Значит у неё появляется простор для творчества, вот она и творит каждый раз разный результат, который может _случайно_ совпадать с предыдущим.

(52) именно так и происходит.
Потому что есть какой нибудь особенный например Ашан, о котором все забыли.

(0) что по этому поводу пишет  msdn ? ,первые он же top это скуль

(54) 2 варианта развития событий:
требую время на анализ. Чем больше торопят - значит тем большая жопа ждет.
- предупреждаю об опасности, а потом нещадно троллю.
Подумать потом сделать условно 40 часов.
Сделать, забить НСИ, потом переделать -  400.
Ещё ни разу быстрое решение не оказалось действительно быстрым

(53) СУБД прочитает дерево индекса, а не таблицу данных, если в дереве есть необходимые поля.

(57) в случае кластерного индекса, о котором тут идёт речь, он хранится вместе с данными

(56) Есть еще два варианта развития:
- предупреждаю, а факап не наступил, троллить некого )
- беру время на анализ, делаю все по фен-шую, а оно не пригождается ни разу

(59) Счастливый человек.

(60) У меня все наоборот. Переделка функционала занимает раз в 10 больше времени, чем его разработка.
И это постоянно, я уже заипалсо всем что то доказывать. "Сделаем запустим, остальное как нибудь"
И вот уже сколько мест работы поменял - одно и то же

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

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

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

(62) + Но тогда это будет работать только для кластерного индекса, отражающего порядок добавления записей в таблицу. И как раз для таблиц ссылочных типов 1С оно так и есть. 1С специально в гуиде временную составляющую ставит в начало, чтобы минимизировать вставки в середину индекса.
Тогда теоретически можно сгенерить такой гуид для элемента справочника через УстановитьСсылкуНового, который "сломает" выдачу "одного и того же" в "ПЕРВЫЕ 1".

(65) Что-то ты повторяешь (51) :)

(66) Действительно :)

Вот что пишет msdn

Если вы используете TOP с предложением ORDER BY, в результирующий набор включаются только первые N строк отсортированного результата. В противном случае TOP возвращает N строк в неопределенном порядке.

В инструкции SELECT всегда указывайте ORDER BY вместе с предложением TOP. Дело в том, что это единственный предсказуемый способ отбора строк предложением TOP.

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

(70) "и SQL будет использовать его" - почему?

(71) Ну дык читать некластерный индекс проще, чем кластерный. Там полей меньше.

(72) абсолютно одинаково

Ну вот, началось

(72) Для ПЕРВЫЕ 1? Крутая оптимизация.

(75) А какая разница для "первые 1" читать кластерный или некластерный?

Да и даже для "ПЕРВЫЕ 1000 Ссылка, Наименование" я сильно сомневаюсь, что оптимизатор будет специально искать вторичный покрывающий индекс при отсутствии явной сортировки.

(77) + Вместо того, чтобы тупо взять первые 1000 по кластерному индексу. Там оптимизировать уже нечего.

(73) SQL-ю пофиг на строки. Ему важен размер строки.

Я просто оставлю это здесь
http://prntscr.com/olx55u

Тоже был удивлен и тоже задался вопросом, почему так.

Нашел даже в msdn объяснение, выкладывал на мисте.

(79) думаешь он всю строку зачитывает, даже если всего 1 поле?

Но пока вот это
https://stackoverflow.com/questions/27193877/why-nonclustered-index-scan-faster-than-clustered-index-scan

(80) Надо же. Век живи - дураком помрешь.

(83) Спасибо за инфу. До этого момента не натыкался.

Насколько sql не хочет юзать кластерный индекс
http://prntscr.com/olx8oo

(80) можно явно хинт и посмотреть план

(81) я тоже нашел и выкладывал.
Там очень четко сказано, что количество полей в индексе - один из параметров принятия решения)

(87) Зачем?

но это уже не чистый эксперимент а подсказка оптимизатору скуль и это зачем то поидумал

(89) так хинты вроде и призваны менять поведение явно

(30)
>Аналогично задачи определения типа. Тут не важно какой конкретно элемент мы получим и сколько их - важно, что они там вообще есть.

тип есть, а записей может и не быть.
поэтому ПЕРВЫЕ 0.

(92) https://youtu.be/Iy7-GGuxaiI