Какая разница куда положить мелочь - в карман джинсов, в кошелек, в копилку ? Тоже самое с данными, которым все равно где лежать, ибо команда select * from распознается всеми серверами баз данных.


Помониторь запросы то, прежде чем позориться.

Зайди в закрытый топик про 1це, там неоднократно конфигурастов тыкали носом в результаты трассировки профайлера.


Ну если 0 тоже считать "неоднократно".

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

Т.е. вы хотите сказать что все DBMS абсолютно одинаковы с точки зрения, как вы выразились, "хранилищ"?


Тссссссссссссс. А то он на полный серьез попросит Вас объяснить чем DB2 отличается от MSSQL и зачем эти придурки из IBM именно так все сделали.

автор
Я хочу сказать, если оптимально не использовать все возможности СУБД, то большой разницы в производительности между MSSQL, DB2, Postgree SQL почуствовать не удасться, а 1Ц НЕ УМЕЕТ ОПТИМАЛЬНО ИСПОЛЬЗОВАТЬ ПЛАТФОРМУ СУБД


Доказательства есть? Так вот сказать: "Она не умеет", можно про что угодно.

Кстати, "select * from" быстрее всего работает на текстовых файлах. Так что, ждем версию сервера 1С, которая будет работать с OLEDB и гоу-гоу Simple OleDB Provider?

Пример запроса 1С. Это выборка для списка документов.

exec sp_executesql N'SELECT TOP 35
_Document340_R._Date_Time _A1,
_Document340_R._Number _A2,
_Document340_R._Fld7948 _A3,
_Document340_R._Fld7956 _A4,
_Document340_R._Fld7945RRef _A5RRef,
_Document340_R._Fld14643 _A6,
_Document340_R._Fld17323RRef _A7RRef,
_Document340_R._Fld7957 _A8,
_Document340_R._Fld7944RRef _A9RRef,
_Document340_R._Fld7964 _A10,
_Document340_R._Fld7955 _A11,
_Document340_R._Fld7954RRef _A12RRef,
_Document340_R._Fld7943RRef _A13RRef,
_Document340_R._Fld7962_TYPE _A14_TYPE,
_Document340_R._Fld7962_RTRef _A14_RTRef,
_Document340_R._Fld7962_RRRef _A14_RRRef,
_Document340_R._Fld14644 _A15,
_Document340_R._Fld7952 _A16,
_Document340_R._Fld14642 _A17,
_Document340_R._Fld7953RRef _A18RRef,
_Document340_R._Fld7949RRef _A19RRef,
_Document340_R._IDRRef _A20RRef,
_Document340_R._Marked _A21,
_Document340_R._Posted _A22,
_Reference72._Description _A23,
_Reference89._Description _A24,
_Reference8._Description _A25,

CASE
WHEN _Document340_R._Fld7962_TYPE = 0x08 AND _Document340_R._Fld7962_RTRef = 0x0000015E
THEN CAST(_Document350._Number AS NVARCHAR(50))
WHEN _Document340_R._Fld7962_TYPE = 0x08 AND _Document340_R._Fld7962_RTRef = 0x0000006C
THEN _Reference108._Description
END _A26,

_Document350._Date_Time _A27,
_Reference78._Description _A28,
_Reference63._Description _A29

FROM

_Document340 _Document340_R WITH(NOLOCK)

LEFT OUTER JOIN _Reference63 WITH(NOLOCK)
ON _Document340_R._Fld7949RRef = _Reference63._IDRRef

LEFT OUTER JOIN _Reference78 WITH(NOLOCK)
ON _Document340_R._Fld7953RRef = _Reference78._IDRRef

LEFT OUTER JOIN _Reference108 WITH(NOLOCK)
ON _Document340_R._Fld7962_TYPE = 0x08 AND _Document340_R._Fld7962_RTRef = 0x0000006C AND
_Document340_R._Fld7962_RRRef = _Reference108._IDRRef

LEFT OUTER JOIN _Document350 WITH(NOLOCK)
ON _Document340_R._Fld7962_TYPE = 0x08 AND _Document340_R._Fld7962_RTRef = 0x0000015E AND
_Document340_R._Fld7962_RRRef = _Document350._IDRRef

LEFT OUTER JOIN _Reference8 WITH(NOLOCK)
ON _Document340_R._Fld7943RRef = _Reference8._IDRRef

LEFT OUTER JOIN _Reference89 WITH(NOLOCK)
ON _Document340_R._Fld7954RRef = _Reference89._IDRRef

LEFT OUTER JOIN _Reference72 WITH(NOLOCK)
ON _Document340_R._Fld17323RRef = _Reference72._IDRRef

WHERE

_Document340_R._Date_Time = @P1 AND _Document340_R._Fld7949RRef = @P2 AND _Document340_R._Fld7962_RRRef = @P3

AND
_Document340_R._Fld7962_RTRef = @P4 AND _Document340_R._Fld7962_TYPE = @P5 AND _Document340_R._Date_Time >=

@P1 AND
_Document340_R._Date_Time <= @P6 AND _Document340_R._IDRRef <= @P7 OR
_Document340_R._Date_Time = @P1 AND _Document340_R._Fld7949RRef = @P2 AND _Document340_R._Fld7962_RRRef = @P3

AND
_Document340_R._Fld7962_RTRef = @P4 AND _Document340_R._Fld7962_TYPE = @P5 AND _Document340_R._Date_Time >=

@P1 AND
_Document340_R._Date_Time <= @P6 AND _Document340_R._IDRRef IS NULL OR
_Document340_R._Date_Time < @P1 AND _Document340_R._Fld7949RRef = @P2 AND _Document340_R._Fld7962_RRRef = @P3

AND
_Document340_R._Fld7962_RTRef = @P4 AND _Document340_R._Fld7962_TYPE = @P5 AND _Document340_R._Date_Time >=

@P1 AND
_Document340_R._Date_Time <= @P6 OR
_Document340_R._Fld7949RRef = @P2 AND _Document340_R._Fld7962_RRRef = @P3 AND _Document340_R._Fld7962_RTRef =

@P4 AND
_Document340_R._Fld7962_TYPE = @P5 AND _Document340_R._Date_Time >= @P1 AND _Document340_R._Date_Time <= @P6

AND
_Document340_R._Date_Time IS NULL

ORDER BY

_Document340_R._Date_Time DESC,
_Document340_R._IDRRef DESC

SELECT @@TRANCOUNT', N'@P1 datetime,@P2 varbinary(16),@P3 varbinary(16),@P4 varbinary(4),@P5 varbinary(1),@P6

datetime,@P7 varbinary(16)', {ts '2006-10-18 00:00:00'}, 0xBF4A00093D13EA1011DB0842D2DA804D,
0xBC1000093D13EA1011DB17C346223ABC, 0x0000006C, 0x08, {ts '2006-10-20 23:59:59'},
0x916600093D13EA1011DB5F549478DB81

И вот, в догонку, ответ спеуиалистов 1С на сообщение о неоптимальной трансляции запроса

"Ситуацию удалось воспроизвести. Причиной замедления работы является особенность поведения оптимизатора запросов MS SQL Server 2000, в результате которой он иногда выбирает неоптимальный план. При использовании MS SQL Server 2005 такого поведения не наблюдается. В следующих версиях платформы мы планируем оптимизировать работу запросов с использованием «В ИЕРАРХИИ». Пока можно посоветовать следующее: ..."

Вот вам и разница.

XenoX Сильно смахивает на построчный скан!


Это уж точно. Как две капли.


Бъюсь об заклад, что половина JOIN'S можно использовать как INNER ибо столбцы обязательны исходя из БЛ

Ссылки бывают пустыми.

Т.е. сначала мы его (SQL-Server) "раком нагнем", а потом пусть он нам оптимальный план сам выбирает...


Приехали. Если MS SQL гарантированно тормозит на "OR", то возможно это проблема MS SQL, а не клиентов.