В 1С предприятие 8.0 такой вид индексов не используются, есть ли смысл их создать не штатными средствами?

зависит от.

Зависит от чего?

Разве во всех современных БД не кластерные индексы?

(3) 1С - не совсем БД

(2) для чего кластерный индекс?.. что он даст?
(3) а почему должны быть кластерными?..
(4) да, точно.. совсем не RDBMS (не реляционная СУБД)...

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

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

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

хм, а я этого не знал:
http://ru.wikipedia.org/wiki/Индекс_(базы_данных)
Существует два типа индексов: кластерные и некластерные. У каждой таблицы может быть только один кластерный индекс и множество некластерных. При наличии кластерного индекса строки таблицы физически хранятся в заданном порядке и непосредственно связаны с элементами индекса, благодаря чему значительно ускоряется доступ к данным при использовании запросов, использующих данный индекс. Если в таблице нет кластерного индекса, таблица является неупорядоченной. Некластерный индекс, созданный для такой таблицы, содержит только указатели на записи таблицы, в связи с чем при выборке необходимо по крайней мере ещё одно обращение к диску для получения собственно записи.

(8) насчет кластерного выяснили.. теперь вернемся к нашим баранам...
хотя бы один момент, где может быть использован кластерный индекс.. на элементах справочника в 100 000 строк?..

(0) А как это к 1С прицепить?

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

to (11)
Индекс можно ручками удалить и создать как кластерный, вроде.
Таймаут! Подождите 5 сек

(12) таки, сколько ж у тебя позиций номенклатуры?  1 000 000 000 000 000 и они редко меняются?.. тогда флаг в руки...))

я в шоке.

Зачем мне флаг?

(6)Это далеко не так...

(17)Геннадич, ты категоричен :)

(18)Ну хорошо... Это не всегда так...

(19) Когда это не так?

(20)В случае покрывающего индекса...

Например?

Что например?

Например как вам удалось сравнить два совершенно разных понятия или найти между ними противоречие?
Ведь индекс может быть как кластерным так и покрывающим (таблицы RG v7.7).

>>  как вам удалось сравнить два совершенно разных понятия или найти между ними противоречие

Смысл вопроса от меня ускользает...

>> индекс может быть как кластерным так и покрывающим

Покрывающий индес является некластерным по определению...

А будут ли запросы сгенерированные 1С использовать эти индексы?

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

Что вы называете покрывающим индексом?
Так я называю индекс покрывающим для запроса если он содержит все поля нахящиеся в разделе условия запроса (говоря буквально текст после WHERE).
В такой трактовке для запроса объекта справочника индекс является покрывающим.
Так как содержит только ссылку.
to (27)
Выбор есть всегда и определяется он статистикой.

(28)Это ваше личное неправильное понимание... Определение покрывающего индекса для SQL-сервера, мягко говоря, несколько отличается от него...

(28)Это ваше личное неправильное понимание покрывающего индекса.

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

(31)В каких именно книжках? В правильных книжках пишут несколько иначе...

И что же пишут в правильных книжках?

В правильных книжках пишут следующее:

"
Covering index.

A covering index is a form of composite index that includes all the columns referenced in SELECT, JOIN and WHERE clauses of a query. This strategy reduces logical and/or physical I/O and increases query performance. SQL Server does not have to look up the actaul data in the table, because the index already contains the data you are looking for.

...

Facts to consider about indexes that cover queries:

- only nonclustered indexes cover queries. Indexes that cover queries contain all the required data of a query in the leaf level of a nonclustered index.

- indexes must contain all columns referenced in th query. An index that covers a query must contain all columns that are referenced in the SELECT, JOIN and WHERE clauses...

- no data page access is required. When a query is covered by an index, the query optimizer does not access the data pages, because all the required data is contained in the index. The amount of I/O is significally reduced.
"

Это цитата из "Microsoft Official Course 2073B. Programming a Microsoft SQL Server 2000 Database"...

PS. Перевод нужен?

Нет, спасибо.
И вообще спасибо.