Хочу индекс в SQL таблице по 4-м полям.
Как это сделать ?
Будет ли жить ?

(0) Мож  ........но в DDS придедтся дописать.

Проще версию обновить

А зачем, SQL запросы более изощренные можно писать, чем 1С-овские

(1) Да это то полбеды !
тут экспериментировали - один справочник на две базы делали  переписыванием dds - работает !

(2) АААА !!!!!  На какую ?  7.7 на 8.0 ???
Неть. Это у меня другая пестня будет...

Как индексы помогут запросам? Ну-ка, ну-ка?

(3)  Ну, да, да да !!!  Без индексов таблица долго выбирается - происходит полный перебор данных (даже с SQL запросом -это долго) с индексами должно лететь раз в 5-6 быстрее...

Строится полный индекс по превым измерениям. Если у тебя четыре измерения идут начиная с првого подряд - вот тебе и сводный индекс.

(6) :-)
Текст
"Microsoft Corporation Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD MCSE, MCDBA"
Со страницы 320 и далее (пока что сам бьюсь-разбираюсь).

типовые запросы в журналах документов при отборе по графе отбора имеют как раз индексирование по индексу, включающему индекс значения и индекс Дата_Время.
Но это Индекс составной по 2-м параметрам.

Select COUNT(*) from _1SJOURN(NOLOCK) where IDJOURNAL=? and DATE_TIME_IDDOC>=? and DATE_TIME_IDDOC<=? and DATE_TIME_IDDOC<=?

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

(8) Стучу в аську за подробностями...

(9) ну ...это ... зайди в EM добавь в индекс ишо 2 поля какие тебе нравятся....

(11) Готов попробовать и проверить жизнеспособность!  Как это сделать ? (как можно подробнее)

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

Действительно, в таблице регистра есть индекс (первый), включающий все измерения

(9) В поиск + http://www.sinor.ru/~my1c/knowhow/jur_otb.html

(14) пройденный этап ;-)  не канает.
на SQL наш выбор :  
Книга знаний: Множественный отбор в журналах и справочниках 7.7 заменой запросов SQL

Абалдеть...

(11) Дак что, как ???

(17) Открой QA. Выбери свою базу. Найди анитресующую таблицу. Открой ее индексы. Щелкни на интересующем правой кнопкой. Дерзай.

EM Design таблицы, Manage Index/Keys  Вот что нужно было.
Ну и плюс DDS переписать. Ладно, завтра буду "Змия запускать" по результатам - доложусь ;-)

(19) Даже ДДС ненада переписывать

(0) по 4-м полям чего?
P.S. а чем тебя не устраивают индексы по каждому реквизиту, которые 1С расставляет? Если внимательно почитать инструкцию к 1С, то не нада ничо шаманить с DDS и т.п.

(6) странно, шо ты этого не знаешь...

(22) Да ладно... что-то и знаю :)

Рапортую. Оно взлетело.
Да еще как !

Исходники:
<a href=Книга знаний: Множественный отбор в журналах и справочниках 7.7 заменой запросов SQL знаний: Множественный отбор в журналах и справочниках 7.7 заменой запросов SQL</a>

в Microsoft SQL Server открываем Enterprise Manadger,
выбираем нашу SQL базу, находим нужную таблицу данных, отвечающую за документ - можно юзать как таблицу шапки так и таблицу табличной части
(определить какую надо можно с помощью 1cv7.dds или прогами типа ViewDD(c)ABFedotov@yandex.ru, или чем-то подобным - можно посмотреть на 1cpp.ru)

На выбранной таблице клик правой кнопкой мыши, команда "Design Table",
В тулсах Кликнуть кнопку "Manage Indexes/Keys..."
У индекса таблицы (единственного для таблиц документа) добавить индексируемые поля (опять же посмотреть какие - dds или вьюер). Закрыть измененную таблицу с сохранением данных.

В файле 1Cv7.dds найти блок, описывающий данный документ (таблицу данных), добавить перечень индексируемых полей.

В 1С. - в журнале, которому выламываем руки(моск) (с применением указанного исходника) заменяем запрос.
Запрос начального вида

vk_hook.ТекстSQL="Select * from _1SJOURN(NOLOCK INDEX=JOURNAL) where IDJOURNAL=? and DATE_TIME_IDDOC>=? and DATE_TIME_IDDOC<=? order by IDJOURNAL, DATE_TIME_IDDOC";

Меняем на
   НовыйЗапрос1=
       "Select *
       |from
               |_1SJOURN(NOLOCK)
       |left outer join НАШАТАБЛИЦА (NOLOCK INDEX=PK_DH_Док)
       |where
       |"+СтрДопУсловий+"
       |_1SJOURN.IDJOURNAL=?
       |and _1SJOURN.DATE_TIME_IDDOC>=?
       |and _1SJOURN.DATE_TIME_IDDOC<=?
       |order by DATE_TIME_IDDOC";
       vk_hook.НовыйSQL=НовыйЗапрос1;
           vk_hook.УстановитьЗаменуSQL();

Где PK_DH_Док - это имя индекса - того, который мы меняли.

В журнале ставим соответствующие поля выбора значений и прописываем процедуры обработки действий в соответствии с исходниками.


РЕЗУЛЬТАТ.
Журнал документов с общим количеством документов нужного типа около 5 000 в месяц. Замена запроса без индекса - 35-30 сек., с индексом - 0,5 сек.

Фишка (сам искал долго - некому подсказать было):
INDEX=... ставится только у описания одной таблицы в запросе.
первой таблицей необходимо оставить таблицу _1SJOURN.

ROMIX, тебе респект и с меня много пива при встрече.

Вот тока нажо ДДС курочить после каждого сохранения базы...А если оно два три раза в неделю ? Пусть лучше 35 секунд ждут.

(25) Напрягся.
Попроверял...

Действительно, при добавлении, удалении реквизитов (любых новых полей в любых таблицах) в dds меняется блок, описывающий этот документ. Он возвращается к исходному.

Индексы в таблице SQL Слетают к исходным если реквизиты добавлялись именно у того документа, чью таблицу индексировали, если удалялись реквизиты у любого объекта.

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

(26) Молодо-зелено :)
http://www.sdteam.com/?tid=1928

"Век живи- век учись"(с)
"Учиться никогда не поздно"(с)
Да мы ж и не против ;)

Ой, как же это сложно то  - впитывать и применять в конце дня 22-го февраля...
С наступающим праздником, мужчики !

(1,3,20) кстати, ддс у скуля вообще для мебели...
недавно в нем искал поля(добавил новые реквизиты в справочник) - не нашел, пришлось убить и пересоздать, и только тогда ддс начал отражать реальную картину...

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

и вообще на ToySQL же можно реализовать создание индекса на таблице. с контролем изменения конфигурации.

(32) Засада в том, что ToySQL не дружит с 1с++ в одной базе.
А там уже столько наваяно...

Да и полезно знать истоки и принципы - тогда и писать можно без дальнейшей оптимизации.

(31) да мне как бы и одного хватает :-)
Проверил - так-то все работает и летает.

Рапортую.
При изменении структуры конфигурации в 1С 7.7 - при сохранении летят все измененные индексы, переписывается DDS.
Решил в качестве индексов вообще использовать Primory Key таблицы.
Нарисовал скрипты, которые автоматом  меняют и индекс в SQL таблице и строки в DDS-файле.

Выкладываю тексты.

скрипт изменения primory key (положить в файл, расширение .sql):
Путь к нему будет, например,
C:\bases\ChangeSQL\DH8404_change.sql


USE [MyBase]
GO

--Перепись Primary Key у таблицы лотов DH8404

BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
ALTER TABLE dbo.DH8404
   DROP CONSTRAINT PK_DH8404
GO
ALTER TABLE dbo.DH8404 ADD CONSTRAINT
   PK_DH8404 PRIMARY KEY CLUSTERED
   (
   IDDOC,
   SP8384,
   SP8383,
   SP8823,
   SP8385,
   SP8393,
   SP14327,
   SP8442,
   SP16833,
   SP16832,
   SP15755
   ) ON [PRIMARY]

GO
COMMIT


JAVA-cрипт изменения DDS-файла (замена строки)
текст - в файл с расширением .js
Путь к нему будет, например,
C:\bases\ChangeSQL\DH8404_change.js


// искомый блок текста - этот текст надо удалить
var FindingText = /I=PK_DH8404                      \|of IDDOC      \|1     \|IDDOC/g;

// новый текст - этот текст надо вставить
var NewText = "I=PK_DH8404                      |of IDDOC      |1     |IDDOC,SP8384,SP8383,SP8823,SP8385,SP8393,SP14327,SP8442,SP16833,SP16832,SP15755";
//var NewText = "I=PK_DH8404";

// Путь к файлу в котором проводится замена
var SearchingFile="C:\\bases\\MyTestBase\\1Cv7.dds";            

var WSHShell = WScript.CreateObject("WScript.Shell");
var ForReading = 1, ForWriting = 2, ForAppending = 8;
var TristateUseDefault = -2, TristateTrue = -1, TristateFalse = 0;
var fso = new ActiveXObject("Scripting.FileSystemObject");

FileModyfy();
WSHShell.Popup("It's done.");

function FileModyfy() {
currentFile = fso.GetFile(SearchingFile);
if (currentFile.size==0) return;

// Читаем файл, формируем строку для поиска
FileHeader = currentFile.OpenAsTextStream();
FileString = FileHeader.ReadAll();
FileHeader.Close( );

// ищем строку FindingText в сформированной "строке для поиска"
if(FileString.search(FindingText)>0){
// заменяем текст
FileString = FileString.replace( FindingText, NewText);
FileHeader = currentFile.OpenAsTextStream(ForWriting, TristateUseDefault);
FileHeader.Write(FileString);
FileHeader.Close( );
};
}


написать батник с текстом:

osql -S MyServer -E -i C:\bases\ChangeSQL\DH8404_change.sql
C:\bases\ChangeSQL\DH8404_change.js


Неудобства - запускать батник после записи внесенных изменений в структуру 1С.
Плюсы - ускорение в разы SQL-запросов (про сравнение SQL с типовыми - Вы уже сами все понимаете). На моих запросах производительность выросла в 40 раз. (0,9 сек. против 35 сек.)

Отдельные спасибы:

NS, Иде_я, Ждинн, romix.

Ну, и мне, само собой :-)

(35)
OpenConf + небольшой скриптик = не надо запускать ручками батник для правки dds.

(37) Да, гламурный бантик, согласен, но надо же и еще кому-то дать повод для творчества :-)