Доброго времени суток!

Вопрос к знатокам 1С и MS SQL.

Исходные данные. Есть 1С 7.7 под MS SQL 2000. Из 1С средствами MS SQL вытягиваюся данные. Проявилась проблема - для SELECTа хочется иметь дополнительные индексы, чтобы оптимизировать запрос.

Читал http://softpoint.ru/article_id15.htm . Предлагаемый путь понятен. Но уж очень не хочется ничего править в базе данных, а именно, системную хранимую процедуру. Хотелось бы обойтись только созданием своих объектов, которые не будут мешать 1С. В связи с этим видится такой путь. Создаем представление на таблицу. К этому представлению создаем индексы. Ну, и далее, работаем только с представлением. Если верить http://www.softpoint.ru/article_id4.htm , то представления, вроде бы, не влияют на верификацию в 1С. А вот как насчет индексов к этим представлениям? Может кто сталкивался или есть мысли по этому поводу?

Заранее, спасибо!

Алексей2003,
> SQL2000 индекс на представление? =)

Именно так. Если я недостаточно ясно выразился, то, на всякий случай - если верить книге: М.Ф.Гарсиа и др. Microsoft SQL Server 2000. Справочник администратора, стр.452: "Индексированные представления. SQL Server 2000 позволяет вам создать индекс по представлению ... Индекс создается с помощью оператора T-SQL CREATE INDEX ... Единственным отличием является то, что вместо имени таблицы вы указываете имя представления".

Leierkastenmann,

Спасибо!

Информация очень ценная! Попробую двинуться в этом направлении. Все же это лучше, чем править системную хранимую процедуру.

Еще раз, спасибо!

Leierkastenmann,

Я тоже сторонник такого подхода. Но к сожалению, в моем случае трудно не обойтись без дополнительных индексов. В SELECTе участвует табличка. По ней нужны агрегированные данные типа CONT(*). У этой 1С-ной таблички только PRIMATY KEY по Id. Больше никаких индексов нет. А агрегирование нужно по другим полям. Вот и выходит FULL SCAN.

Я рассматриваю еще один путь. Создать свою табличку. Отдельную. И повесить на 1С-ную табличку триггеры, которые собирают агрегированную информацию из этой 1С-ной аблички. И здесь еще 2 вопроса. Как посмотрит 1С на чужеродную таблику? Если плохо, то можно создать свою табличку в отдельно базе. Хотя, понятно, это не здОрово. И еще. А как посмотрит 1С на чужие триггера к своим таблицам?

Может еще что-то можно? Типа материализованных представлений из Oracle? С MS SQL я давно плотно не работал, последний раз в прошлом тысячелетии. Последние 10 лет только Oracle.

Leierkastenmann,

Про чужеродные таблицы и триггеры хорошая новость! Спасибо!

Дело в том, что у меня ситуация не совсем типичная. Сама 1С в данной конфигурации очень мало загружена. Она служит перевалочной базой между торговыми представителями, которые вводят заказы через смартфоны, и основной Oracle базой данных. Моя конечная цель -иметь фиксированное время отклика системы, пусть и не самое оптимальное, но фиксированное. А сейчас база 1С постепенно растет, соответственно, постепенно растет время отклика. И вот на днях время отклика на SELECT превысило 30 секунд, установленных Микрософтом в компоненте .NET. Сейчас я просто увеличил таймаут до 300 секунд. Минимум на год этого хватит. И пользователи не будут жаловаться. Такова ситуация. Мне важно все реализовать внутри программы на C#. И зафиксировать время отклика. С помощью отдельной таблицы и триггеров, насколько я понял, это возможно.

> Ну и в целом, где будет выигрыш, если при каждой операции триггер
> будет заниматься подсчетами в неиндексированной табличке
> и складывать данные в другую табличку?
В моем случае неиндексированость 1С-ной таблицы при тригерах как раз роли не играет. Главное, чтобы моя отдельная таблица для агрегированных данных была индексирована. Я до этой таблицы 1С-у нет никакого дела.

Егоров Александрtsandrew,

Если достаточно только индексов на родных 1Сных табличек - эти индексы может создать и сама 1Ска, и даже может их считать своими родными индексами. Читать тут . :)

Спасибо!

Тоже возможный вариант. Я уже натыкался на возможность правки 1cv7.ddx и подобный скрипт. Здесь мне не понравились только то, что приходится трогать родную 1С. Но возможно это наименьшее зло.

VladimirKrLeierkastenmanntsandrew,

Несколько лет назад пытался сделать такое, но представление, чтобы его можно было индексировать, должно быть SCHEMABINDING. А это означает, что нельзя будет в используемые таблицы вносить изменения, поскольку у 1ски штатными средствами это drop и create table. То есть придется перед обновлением конфигурации удалять представление, а потом пересоздавать его.

+1, Но это часто стоит того. Главное иметь ввиду, как ведет себя index view в различных версиях SQL. Я однажды столкнулся свот этим: Index Scan и индексированное представление

Спасибо!

Буду иметь это в виду!