gifts2017

Занимательные запросы

Опубликовал Трактор Трактор (Трактор) в раздел Программирование - Практика программирования

Как выглядит "кухня" запросов 1С? Те запросы, которые пишем мы в 1С преобразуются в запросы к SQL серверу. Причём весьма неочевидным сходу способом. Рассмотрим один простой случай.

Итак допустим мы пишем в 1С в консоли запросов:

ВЫБРАТЬ
   Товары.Ссылка,
   Товары.Поставщик.Наименование
ИЗ
   Справочник.Товары КАК Товары

В запросе к sql серверу он будет выглядеть так:

SELECT
   T1._IDRRef,
   T2._Description
   FROM _Reference7 T1
   LEFT OUTER JOIN _Reference8 T2
   ON T1._Fld109RRef = T2._IDRRef

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

Вроде бы всё ясно. Но глядя в логи PgSQL мы видим что от 1С пришёл не один запрос, а ещё несколько, попроще:

SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\214\\376\\314j}\\362'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\214\\376\\314j}\\363'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\214\\376\\314j}\\364'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\214\\376\\314j}\\365'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\214\\376\\314j}\\366'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\215\\004=q\\000w'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\241\\000\\015\\210C\\315\\033\\021\\334\\216\\251-\\227\\247I'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\241\\000\\015\\210C\\315\\033\\021\\334\\216\\254\\324q\\326\\307'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\241\\000\\015\\210C\\315\\033\\021\\334\\216\\263`\\367\\013M'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\242\\000\\015\\210C\\315\\033\\021\\334\\221\\003\\235\\177\\321\\013'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\242\\000\\015\\210C\\315\\033\\021\\334\\221\\016Q\\000\\330\\200'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\214\\242\\000\\015\\210C\\315\\033\\021\\334\\221\\021\\361ix.'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\215:\\000\\015\\210C\\315\\033\\021\\3352\\033\\247\\243\\012\\256'::bytea
;
SELECT
   T1._IDRRef,
   T1._Description
   FROM _Reference7 T1
   WHERE T1._IDRRef = '\\215:\\000\\015\\210C\\315\\033\\021\\3352\\033\\247\\243\\012\\257'::bytea

Что это за запросы? Хе! Это запросы на получение представления ссылки в результатах, отображаемых на экране.

 

Пробуем оптимизировать наш запрос. Попробуем получить представление и посмотрим сумеет ли 1С понять что оно уже получено и повторно его получать ненадо.

ВЫБРАТЬ
    Товары.Ссылка,
    Товары.Наименование,
    Товары.Представление,
    Товары.Поставщик.Наименование
ИЗ
    Справочник.Товары КАК Товары

 

В PostgreSQL пойдёт такой запрос:

SELECT
    T1._IDRRef,
    T1._Description,
    T1._IDRRef,
    T1._Description,
    T2._Description
    FROM _Reference7 T1
    LEFT OUTER JOIN _Reference8 T2
    ON T1._Fld109RRef = T2._IDRRef

но тут же в логах мы видим ещё 15 простых запросов вида

SELECT
    T1._IDRRef,
    T1._Description
    FROM _Reference7 T1
    WHERE T1._IDRRef = '\\214\\240\\000\\015\\210C\\315\\033\\021\\334\\214\\376\\314j}\\362'::bytea

Посчитав число отображаемых строк мы убеждаемся, что 1С не сопоставила ссылку и представление. Это вобщем логично, поскольку отображаемая таблица значений не связана с данными и поэтому 1С вынуждена подтягивать представление ссылки по мере отображения на экране.

Однако есть способ заставить 1С делать только один запрос. Для этого перепишем его вот так:

ВЫБРАТЬ
    Товары.Представление,
    Товары.Поставщик.Наименование
ИЗ
    Справочник.Товары КАК Товары
Упорядочить по
    Товары.Представление // Хочется, всё-такивидеть упорядоченные товары

При этом в Postgre отправится такой запрос

SELECT
    T1._IDRRef,
    T1._Description,
    T2._Description
    FROM _Reference7 T1
    LEFT OUTER JOIN _Reference8 T2
    ON T1._Fld109RRef = T2._IDRRef
    ORDER BY (T1._IDRRef), (T1._Description)

Запрос ушёл один, его результат отобразился без лишних обращений к базе.

Счастье? Нет!

И вот почему:

1. Несмотря на то что мы сказали "Упорядочить по Товары.Представление" произойдёт упорядочивание по внутренним идентификаторам.

2. Представление получает из базы и идентификатор и наименование, но это не даёт нам никаких преимуществ по сравнению с простой выборкой наименований поскольку идентификатор не доступен разработчику конфигурации. Из языка 1С доступно только текстовое описание.

По сути запрос к Представлению даёт меньше чем к наименованию.

ВЫБРАТЬ
    Товары.Наименование,
    Товары.Поставщик.Наименование
ИЗ
    Справочник.Товары КАК Товары
Упорядочить по
    Товары.Наименование

В PgSQL

SELECT
    T1._Description,
    T2._Description
    FROM _Reference7 T1
    LEFT OUTER JOIN _Reference8 T2
    ON T1._Fld109RRef = T2._IDRRef
    ORDER BY (T1._Description)

Эта статья навеяна двумя статьями http://infostart.ru/public/61624 и http://infostart.ru/public/61933 .

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Рытов (Арчибальд) 02.12.09 14:54
Вот что, мнительный ты наш (это на коммент в другой ветке).
Будет новая беда - прямиком спеши сюда © Л.Филатов. В смысле, обращайся. 8-)
Ты уже чуть штрихкоды не сгноил в безвестности. :o
2. Андрей (ghostishe) 02.12.09 14:57
Я ожидал в конце все-таки иной развязки, и надеялся, что будет "правильный запрос" оптимизированный... =) Но хэппи энда не было. Горькая правда. За правду плюс.
Арчибальд; +1 Ответить 2
3. Юрий Тимофеев (Tatitutu) 02.12.09 14:58
Однако сомнения остались. Не превратится ли Инфостарт в мусорку для специалистов? Ведь и эта публикация и моя довольно очевидны...
из твоего поста

Специалисты по мусоркам не шастуют, это пререгатива гиен

Развей сомнения, небоись быть услышанным и тебя услышат, только когда объясняешь , объясняй так чтобы понял не только он , но и его бабушка...
Не стестняйся простых и достуных слов.
Вся твоя статья (хорошая статья и мне понятная) ,
но ты этой статьей ХОТЕЛ -НЕ ПОЛЬЗОВАТЕЛЮ (посетителю нашего портала ЧТО-ТО новое донести,сдесь собираются СПЕЦИАЛИСТЫ разного уровня, кто пришел научить , а кто поучится) а ПОКАЗАТЬ что на такие "сопли" у настоящего СПЕЦИАЛИСТА нету времени и все это давно знают.
Но это твое мнение и я его уважаю.
4. Александр Рытов (Арчибальд) 02.12.09 15:11
(2)
Но хэппи энда не было. Горькая правда.

+ душ Шарко ;)
5. Трактор Трактор (Трактор) 02.12.09 15:20
(3)
Специалисты по мусоркам не шастуют, это пререгатива гиен

Вот именно! Среди элементарщины трудно бывает найти что-то интересное. Ну да ладно! Твоё http://infostart.ru/public/61933 народ хвалит, надеюсь и эта статья кому-нибудь пригодится.
6. Юрий Тимофеев (Tatitutu) 02.12.09 15:26
(5) И эта статья ОБЯЗАТЕЛЬНО кому-нибудь пригодится.
Ты передал частичку СВОИХ знаний...ты стал на дорогу УЧИТЕЛЯ.

И еще тебе совет - можно досканально знать предмет, правильно и научно описывать методы, но САМОЕ важное НАЙТИ аудиторию и СПРОС на эти ЗНАНИЯ - в ИТОГЕ - ГЛАВНОЕ чтобы тебя не только УСЛЫШАЛИ , но и ПОНЯЛИ (заинтересовались) (а в этих понятиях колоссальная разница)
адуырщдв; fishca; annak2980; +3 Ответить
7. Алексей Плутенко (Noy) 02.12.09 15:55
Кстати занятная информация.
Не хватает только выводов.
Например: для увеличения производительности системы стоит показывать пользователю уже типизированные значения (Строка, Число, Дата), а ссылки делать не видимыми.
Правда я не уверен, что 1С (даже если скрыть в ТЗ колонку с ссылкой) не будет напрягать базу...

ЗЫ с 8-кой не работаю, мог написать глупость...
8. Александр Рытов (Арчибальд) 02.12.09 16:25
(7) Какую там глупость... Поле непаханное, истины в последней инстанции не найдешь... :D
9. larissa builova (larisab) 02.12.09 16:30
Это интересно, очень даже, но для "для простых 1Сников" это все назывется одним понятием - разименование полей и, не поверишь, но им достаточно. А что уж там в сикулах происходит, проверить им не удастся, серверов на всех не хватит. Большинство работают в файловой режиме, а с SQL запросами так и вообще единицы. Зато ексель - это второй инструмент для пользователей, которые являются заказчиками и что характерно (фуу, как прозаично) кормильцами этих самых "простых 1Сников". Этим и объясняется интерес и плюсики (в ветке про ексель), которыми так любят померяться джедаи Инфостарта.
А вот твоя фраза "Причём весьма неочевидным для простых 1Сников способом" любви и плюсов тебе от них не добавит. ИМХО.
Со всем уважением к твоим знаниям.
p.s. ну и плюс, конечно :)
адуырщдв; mr zafod; Mortal; try2007; Tatitutu; Арчибальд; +6 Ответить 2
10. Трактор Трактор (Трактор) 02.12.09 16:38
(9) У каждого свой опыт. Мне с запросами приходится чаще работать чем с табличным редактором. Пользователи в нашей конторе тоже с Опен офисом редко работают. А Эксель стоит только у троих.

>> твоя фраза "Причём весьма неочевидным для простых 1Сников способом" любви и плюсов тебе от них не добавит
Фразу поправил. Никого не хотел обидеть. Я сам простой 1Сник. В темы SQL только начал вникать. Это отдельная область знаний, поэтому врядли сильно углублюсь в неё.
11. Александр Рытов (Арчибальд) 02.12.09 16:39
(9) Вот так, все по полочкам :)

У меня начинает складываться впечатление, что 1С8+SQL=засада. В отличие от трехсемерочного 1С7.7+SQL7, который Нуралиев с Гейтсом устаканивали...
12. Трактор Трактор (Трактор) 02.12.09 16:40
12 появилось оттого что хотел поправить 10, а в это время Арчибальд добавил своё 11. Раньше выдавалась ошибка, а теперь добавляется новая запись.
(7) >> не уверен, что 1С (даже если скрыть в ТЗ колонку с ссылкой) не будет напрягать базу
Не проверял, но думаю что не будет. А рекомендации, да, такие как ты озвучил.
13. larissa builova (larisab) 02.12.09 16:57
(12) Это я уже заметила, но если бы ты не успел отредактировать 12 коммент, было бы их три тогда?!
Так, что лучше не править все таки ;)
14. Трактор Трактор (Трактор) 02.12.09 17:17
(13)
Так, что лучше не править все таки

Если можно, то хочется :-) Вот на Кубани, помнится было нельзя. Приходилось аккуратнее выражаться.

(2) ghostishe, хотел тебя разочаровать и оптимизировать до одного запроса. Не вышло. Дописал статью на этот счёт.
15. larissa builova (larisab) 02.12.09 18:03
(14) Насколько я помню, здесь тоже было нельзя, но очень просили.
16. Трактор Трактор (Трактор) 02.12.09 21:58
(1)
Будет новая беда - прямиком спеши сюда © Л.Филатов. В смысле, обращайся.

Вот, нашёл ещё одну вещь. Обращаюсь :-) http://infostart.ru/public/62041/
правда глючит на 25-ом релизе 7.7
17. Артур Аюханов (artbear) 03.12.09 09:30
(0), (7)
Эта инфа давно известна, еще со времен 77.
И в рекомендациях лучших собаководов об этом давно написано - например, не выводить в печатную форму объекты, а выводить только их представление/наименование, полученное из запросов.
18. Трактор Трактор (Трактор) 03.12.09 09:53
(17) Конечно известно, но всегда хочется надеяться на лучшее.
Однако сдвиги к лучшему есть. Если таблица связана с данными, то запрос выбирает по 20 строк в толстом клиенте и по 23-42 в тонком клиенте. Всё меньше запросов.
Не знаю как у других, а у меня до недавнего времени были иллюзии относительно виртуального поля Представление. Всё надеялся что по нему должно правильно сортироваться и что использование этого поля даёт выигрыш в скорости. Нифига подобного! Теперь мне вообще непонятно зачем нужно поле Представление.
19. Дмитрий Павлик (DimaP) 03.12.09 15:22
Офигеть!
Получается, что с sql скорость работы с БД не увеличивается ?
мдя...файловый вариант 1с тоже нормальное работает и без сбоев.
20. Трактор Трактор (Трактор) 03.12.09 15:34
(19) >> Получается, что с sql скорость работы с БД не увеличивается ?
Во-первых да, не увеличивается. Во-вторых никто и не обещал увеличения скорости. О скорости я в этой статье не говорил вообще.
Опять-таки со времён 7.7 известно правило "Жигули быстро ездят, КамАЗ много везёт". То есть если пользователей мало, то файловая база ничуть не хуже клиент-серверной. А вот если пользователей много, то файловая может просто не сдвинуться с места. Жигули 10 тонн увезти не смогут. И хамер не сможет. А вот КамАЗ увезёт.
Но это всё лирика. Статья не о том. Статья о том что неплохо бы себе представлять во что превращаются запросы внутри 1С. И сколько этих запросов на самом деле идёт в базу. Это позволит избежать ошибок при проектировании алгоритма.
Кстати, в файловой базе запросы, скорей всего, преобразуются точно также как и в клиент-серверной. Только это происходит внутри 1С и посмотреть запросы к таблицам файловой базы не получается. Так что статья актуально и для файловой базы.
21. Трактор Трактор (Трактор) 03.12.09 15:43
20+ А вот запрос, какой идёт к серверу из клиента при открытии группы в форме списка справочника:

SELECT
T1._Code,
T1._Description,
T1._Fld101RRef,
T1._Marked,
T1._IsMetadata,
CASE WHEN (T1._Folder = FALSE) THEN TRUE ELSE FALSE END,
T1._IDRRef,
T1._ParentIDRRef,
(T1._Folder)
FROM _Reference8 T1
WHERE (T1._ParentIDRRef = '\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\00­0\\000\\000\\000\\000'::bytea)
ORDER BY ((T1._Folder)), (T1._Description), (T1._IDRRef) LIMIT 42

Видно что 1С берёт первые 42 записи. Если не хватит, то будет второй запрос. Таким образом от элементов диалога, связанных с данными запросов генерится на порядок меньше чем от таблиц значений, куда помещены ссылки на объекты.
22. Михаил Ражиков (tango) 03.12.09 15:57
(20) "в файловой базе запросы, скорей всего, преобразуются точно также как и в клиент-серверной"
Архисомнительное предположение.
23. Трактор Трактор (Трактор) 03.12.09 16:26
(22) Проверить трудно. Однако ещё труднее предположить что 1С будет изобретать ещё один стандарт обращения к базе и транслировать запрос в один вид для файловой базы и в другой вид для клиент-серверной.
24. Артур Аюханов (artbear) 03.12.09 17:26
(22) ИМХО ты не прав, более прав 23.
25. Vitaliy (idef) 03.12.09 17:38
(24) А вспомните как в клюшках различались результаты запросов в СКЛ и ДБФ версиях особенно на ранних релизах и тогда станет понятно, что движек используется разный. И в восьмерке тоже.
(23) Привильно 1С не будет изобретать новый стандарт обращения к базе - возьмет чей-то готовый :D
26. Михаил Ражиков (tango) 03.12.09 18:17
1ску на с++ слабали?
Тогда и обращение к табличкам, получившимся после парсинга 1Cv8.1CD, не есть обращение к базе, а стандартная для с++ работа с массивами:
http://valera.asf.ru/cpp/book/c02.shtml

а для работы с sql - пользуется тем, что MS дает в распоряжение клиента, да и то не всем

для работы с собственными, не всунутыми в мс-скл, табличками не достаточно сказать, ЧТО надо, но и программировать процесс получения, КАК получить... собственно, это отличие скульных диалектов от "взрослых" языков "программирования"

т.е. внутри 1сины должны быть парсинг скриптовых запросов и на этой основе - 1. формирование запросов к мс-скл, 2.- сишная работа с массивами. 1 -для клиент-сервера, 2 - для файловой версии
27. Ярослав Радкевич (WKBAPKA) 03.12.09 18:26
2(18): насколько я понял из описаний и рекомендаций, когда ты наряду со ссылкой выбираешь представление то если ты начинаешь работать с объектом, например, выводишь в отчет как ссылку, то происходит неявное преобразование ссылки в представление, что естественно влияет на скорость, а когда предсталение получаешь в запросе, тогда неявного преобразования не происходит, имхо, по данным от 1С
28. Михаил Ражиков (tango) 03.12.09 18:29
+(26) на то, что такая "параллельность" имеет место быть, косвенно указывает "параллельность" NULL ( и присутствие NULL в скриптовом языке) и Неопределено
29. gilv (Gilev.Vyacheslav) 03.12.09 19:26
Рекомендую не тратить время на статью, т.е. "-", она практической пользы не несет. Кому надо, до этого и так доковыряются. А постгре вообще зло для любителей халявы.
30. Vitaliy (idef) 03.12.09 19:50
(29) Хмм, не могу согласится. Польза от статьи конечно сомнительная, но вот насчет постгри все-таки не зря 1эсники реализовали его поддержку
31. Игорь Исхаков (Ish_2) 03.12.09 20:12
А всё-таки чем хорош постгре ? Рискну задать вопрос автору.

Не в первый раз встречаю усмешку по поводу использования постгре или короткое "Да ну ..". Как бы предполагается , что спросивший спорол откровенную чушь.
32. gilv (Gilev.Vyacheslav) 03.12.09 20:34
>не зря 1эсники реализовали его поддержку
это называется маркетинг,
на что только не пойдут, чтобы серверный ключ продать 8-)
главное, что потом любители сэкономить начинают любимые истории вроде

Подскажите, никто не встречался с подобной ошибкой при создании базы:

Ошибка СУБД:
ERROR: operator 16946 is not a member of optfamily 17076

CentOS, PosgreSQL 8.3.3-2.1C, 1Cv8.1.15


В версии 8.1.15 включили поддержку PosgreSQL 8.3.8 и 8.4.1, да так включили, что с 8.3.3 перестала 1с-ка работать!
У вас два выхода:
1. Понижать 1с до 8.1.14.
2. Ставить PosgreSQL 8.3.8-2.1C.
Мы поставили 8.3.8 и всё заработало!

задолбало отслеживать стабильные сочетания релизов
DB2 тоже иногда завязывается на особенности очередной версии платформы, но такого бардака в IBM не позволяют себе
33. Анатолий Ситников (acsent) 03.12.09 21:16
>>Поставщик мог ссылаться не только на один справочник, а на несколько, то таких соединений было бы несколько

начал про одно, потом резко перескочил на другое
34. Трактор Трактор (Трактор) 03.12.09 22:14
(29)
Рекомендую не тратить время на статью, т.е. "-", она практической пользы не несет.

Будешь смеяться, но в этом я с тобой согласен. Однако народ считает иначе и меня почти переубедили. На написание этой статьи меня толкнула другая статья где я высказал мнение сходное с твоим. http://infostart.ru/public/61933/#comm комментарий 42.

А постгре вообще зло для любителей халявы.

А тут не соглашусь. Уже год работаю с базой на Постгре и горя не знаю. Этот вопрос мы с тобой уже обсуждали, правда не прилюдно. Админ у нас хороший.

(32)
на что только не пойдут, чтобы серверный ключ продать

Для продажи ключей достаточно было бы поддержки DB2. Тут, ИМХО, другое.

В версии 8.1.15 включили поддержку PosgreSQL 8.3.8 и 8.4.1, да так включили, что с 8.3.3 перестала 1с-ка работать!

ХЗ какие у них трудности. Я в этом не копенгаген. Наверное труднопреодолимые. Да и не так трудно провести одновременное обновление и 1С и Postgre. Просто об этом надо знать.
Мы, например, обновляться будем сразу на 8.2.
Слава, я понимаю твоё возмущение действиями 1С, но не понимаю твоего отношения к слонам. Ведь работают. И хорошо работают.

(33) Перескочил поскольку комментарии к запросу излишни. Там всё ясно. Хотелось ещё сказать что в MSSQL из-за этих соединений можно наткнуться на ограничение в 256 таблиц в запросе. Вообще статья сумбурная, но может кто-то что-то из неё и вынесет. Может прояснится понимание кишок 1С. Мне самуму что-то стало понятнее пока писал.
35. Юрий Тимофеев (Tatitutu) 03.12.09 22:21
(34)
На написание этой статьи меня толкнула другая статья где я высказал мнение сходное с твоим


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

заинтересуй,заинтересовал - поддержи интерес
36. Трактор Трактор (Трактор) 03.12.09 22:38
(35) Tatitutu, не злись, не стоит. Много написал, потом удалил. "Давайте жить дружно" (с)
Tatitutu; +1 Ответить
37. Ярослав Радкевич (WKBAPKA) 03.12.09 23:15
зря спорите, для таких статей support предусмотрел блог, а статья полезная... даже спорить не интересно
Трактор; +1 Ответить 1
38. gilv (Gilev.Vyacheslav) 03.12.09 23:51
(34)

А тут не соглашусь. Уже год работаю с базой на Постгре и горя не знаю. Этот вопрос мы с тобой уже обсуждали, правда не прилюдно. Админ у нас хороший.


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

учиться не хотят

сам по себе постгре вещь мощная, но только в умелых руках

по поводу 1С, у меня нет возмущений
на партнерском форуме это инструмент "управления", как еще их направлять на потребности
просто важно понимать, где компромис между количеством, критичностью ошибок с одной стороны и желанием срубить денег с другой

применительно связки 1С + постгре - иллюзия "на халяву" не настраивает на серьезный лад, это "ловушка" для новичков

39. Игорь <...> (I_G_O_R) 03.12.09 23:51
(29)
А постгре вообще зло для любителей халявы.

а ваш колега Ляшко Юрий, похоже так не считает ;)
40. Трактор Трактор (Трактор) 04.12.09 09:48
(37) >> для таких статей support предусмотрел блог,
Вот об этом я как-то не подумал. Спасибо за подсказку. Попробую начать пользовать блог.
(38)
я не против постгреса, а против выбора тех, кто вообще не одной субд не знает, и пытается с установкой решить еще и вопрос обучения нахаляву замучив вопросами "я новичок, помогите".

gilv, из твоих высказываний можно понять что ты плохо относищься к постгресу. Халявщикам ничего не поможет. Помнишь как мы с тобой ходили к клиенту, который требовал производительности на сервере с 4 Гигами памяти и базой в 160 Гиг? Им не помог МС SQL потому что жмотились на железе.
Прошу тебя точнее указывать адресатов своего раздражения. Не слоны, а жмоты и лентяи. Причём жмоты не только на ПО, но и на железо и на обучение. PosgreSQL тут не виноват.
А я пользую слонов и примеры запросов беру из них. Почему слонов, а не что-то другое? А потому что слоны лицензионно чисты и никто мне ничего не предъявит.
(39) Халявщикам зло всё. Жадины считают что весь мир против них и весь мир им должен.
41. gilv (Gilev.Vyacheslav) 04.12.09 18:01
(40) признаю, постгре меня разочаровал, но раздражают имено любители халявы
буду выражаться точнее, упрек принимаю
42. Павел Чистов (GROOVY) 07.12.09 02:15
Интересно, а автор статьи давно пишет запросы в 1С? Читал ли он рекомендации по оптимизации производительности запросов опубликованных на ИТС? Знает ли автор о функции Представление() для ссылочных полей в запросах?
Жирный минус за то что новичков в заблуждение вводит. Парсер запросов хороший инструмент, но и запросы 1С надо бы знать.
43. Трактор Трактор (Трактор) 07.12.09 08:20
(42) Читал ли ты что я написал? Я говорю не о функции, а о виртуальном поле! Нафига оно надо?
Прежде чем тыкать других в невнимательность сам внимательно прочитай.
Жирный минус за то что новичков в заблуждение вводит.

Новичкам эта статья поможет слабо. Им бы с штатной документацией разобраться. А вот опытным людям неясно зачем нужно виртуальное поле Представление. Зачем, Недостижимый? Зачем при упорядочивании по этому полю происходит упорядочивание по внутренним идентификаторам?
44. Павел Чистов (GROOVY) 07.12.09 17:50
(43) Поле "Представление" это виртуальное поле. Формируемое уже на сервере приложения ПОСЛЕ того как скуль вернет запрос. По этому и обращения к скулю идут, и по этому же сортировать по нему нельзя. Упорядочивание просто не происходит, а не "происходит упорядочивание по внутренним идентификаторам".
45. Трактор Трактор (Трактор) 07.12.09 18:18
(44) GROOVY, обрати внимание на вот эти два запроса, приведённые в статье.
ВЫБРАТЬ
    Товары.Представление,
    Товары.Поставщик.Наименование
ИЗ
    Справочник.Товары КАК Товары
Упорядочить по
    Товары.Представление
...Показать Скрыть

При этом в Postgre отправится такой запрос
SELECT
    T1._IDRRef,
    T1._Description,
    T2._Description
    FROM _Reference7 T1
    LEFT OUTER JOIN _Reference8 T2
    ON T1._Fld109RRef = T2._IDRRef
    ORDER BY (T1._IDRRef), (T1._Description)
...Показать Скрыть

Из 1С в СУБД пошёл запрос с требованием упорядочить по внутреннему идентификатору. Я не знаю внутренностей сервера приложений 1С, может он их как-то ещё сортирует. Однако я так не думаю.

GROOVY, виртуальное поле Представление возвращается строкой. В зависимости от настроек на закладке Данные в конфигураторе оно будет содержать или код или наименование, а для документов и бизнес процессов собираться из вид+номер+дата.
Единственное практическое его применение я вижу для документов и бизнес процессов. В остальных случаях удобнее и быстрее обращаться сразу к коду или наименованию так мы избавим и сервер приложений от ненужной работы и СУБД от лишних выборок и сортировок.
46. Павел Чистов (GROOVY) 07.12.09 18:47
(45)
"Единственное практическое его применение я вижу для документов и бизнес процессов. В остальных случаях удобнее и быстрее обращаться сразу к коду или наименованию"
Это если мы знаем какое представление указано в системе для справочника, а если нет то тут как раз и поможет это виртуальное поле.
47. Трактор Трактор (Трактор) 09.12.09 16:54
(46) Однако вернёмся к нашим баранам. То есть к статье. Я всё пытался получить и ссылку и представление таким образом чтобы табличное поле в консоли запросов не посылало кучу запросов на получение представления ссылки. Возможно ли это? У меня вот не получилось.

Поправлено. Раньше вместо "консоли запросов" было "консоли отчётов"
48. Владимир Чередниченко (bazilisa) 15.12.09 22:07
не знал, не знал
fzt; Rustig; Трактор; +3 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа