Заглянул давеча через плечо знакомого программиста на 1С. Увидал монстроидальные селекты для отчетов на многие страницы. Когда спросил, почему не используешь вьюшки, он ответил что их нет. Посему вопрос:

Правда что-ли в 1C нет вьюшек (view)?
Этого чуда инженерной мыслы полвековой давности?
Или это считается нормальным для людей, которые еще недавно считали ИТОГО и строили отчеты циклом for?

Только давайте не разводить флуд что мол есть временные таблицы. Да, есть. Но нужны именно вьюшки. Почему? Спросите у гугла. Например несколько доводов тут http://www.sql-server-performance.com/2002/derived-temp-tables (К слову о прогрессе, это пост 10 летней давности)

по идее аналогом вьюшек можно с натяжкой считать виртуальные таблицы 1С

(0)>> Или это считается нормальным для людей, которые еще недавно считали ИТОГО и строили отчеты циклом for?

А что в этом стремного или неправильного? Я и сейчас так пишу отчеты для 1с8

Плоха без вьюшек((

(1) Жаль что свои виртуальные таблицы создавать нельзя. Думаю это дело времени.

(0)мой английский хуже русского, но комментарии в ссылке вроде как бы не в пользу вьюшек

С вьюхами я думаю было бы намного проще

в понедельник почитаю, поржу

а, вот автору вброс: почему в SQL Management studio (да и вообще ни в одной IDE по нормальному реализованный не видел) нет конструктора запросов как в 1с?

(8) хорошо что ты не спросил про СКД,
этот вопрос доводит апологетов Java до суицида

а)В 1С есть внешние источники данных, и туда можно добавить вьюх
б) Ораклисты сказали что больше не будут делать вьюхи чтобы 1С брала из них данные, сказали это копроинструмент.
в) могу себе представить что было бы, если 1Сникам дали такую возможность...

(0) "Как вы живете без вьюшек?" - Спасибо, хорошо ;-)

(8) есть там конструктор запросов.

А может ктонить пример привести где было бы удобно использовать вьюшки в 1С. Только воду лить не надо, а конкретно в типовой БП например в документе отражения зарплаты в учёте там то там то и т.д. Я даже пример из пальца высосать не могу полезного применения вьюшки.

(27) Монстроидальные запросы не из-за отсутствия "вьюшек", а из-за гуманитарного склада ума разработчиков. Вместо того, чтобы провести декомпозицию, разбить большой запрос на логически осмысленные подзапросы, связав их через временные таблицы, они создают конструктором монстра..

(0) Хороший вброс, годный.Отвечая на вопрос - живем нормально, получаем в 1,5-2 раза больше, чем вы.

(0) А как вы живете без СКД ?

2(14) Ну, Лучше разбираться и править в запросе сконструированным конструктором, чем например в пакетных запросах ЗУПа, которые вроде и разбиты и декомпозированы, но пока найдешь концы почему в итоговой таблице вот именно такая цифра а не другая, то упреешь
===
2(16) при помощи Кристал Репорта например...

Если серьёзно без вентиляторов, мне кажется что в 1С мы и так уже работаем с готовыми всевозможными агрегированными таблицами (как уже выше сказали виртуальными), а вот представьте что пришлось бы получать итоги или срез последних из скуля напрямую, запросы бы увеличились раз в десять, вот тогда бы и пригодились вьюшки. Просто людям из мира джавы и дотнета надо доносить что мы уже работаем с готовыми маленькими запросами за которыми стоят длиннющие портянки к скулю.

(0) А зачем подглядывал? Завидуешь? Не завидуй бери и пиши...

(18) < а вот представьте что пришлось бы получать итоги или срез последних из скуля напрямую


да это просто сказка была.

(20) А тебе кто-то мешает это сейчас делать?

(13) вьюха по сути шаблон подзапроса, кроме уменьшения кода ничего не дает
была бы она хотя бы параметризованной, тогда да - можно было бы юзать тот шаблон "срез последних на каждую дату"

(17) В СКД не всё можно реализовать для нормального вывода отчета :) на деле, почти и не пользуемся в своих конфах....

(23) к (16).

2Max1986: Неповезло. При попытке перейти на любую другую архитектуру с инструментами 15 летней давности хотя бы, с такой идеологией кодинга прийдется сильно переучиваться.
2Armando: 1cка уже вроде бы с десяток лет на рынке... Еще с десяток подождать?
2Fragster: потому что тру кодер пишет все ручками быстрее всяких конструкторов. Согласен, накидать список полей в конструкторе удобнее, но построить подзапросы, джойны по хитрым условиям, группировки и т.д. лучше вручную
2ЖивойИскопаемый: При чем тут внешние источники? я говорю про внутренние инструменты и данные только в пределах конфигурации. в) Да, уж. Судя по комментам можно догадаться. Понятие code reuse, codestyle, рефакторинг и stinky code (перевод последнего не разрешил вставить антимат) прийдется видать очень долго объяснять.
2ChaiNic: я сразу сказал, временные таблицы - не аргумент. Как минимум страдает производительность. Список недостатков можно сильно продолжить
2Defender aka LINN: Нет уж, я уж лучше буду получать сколько получаю и никогда в жизни не видеть этот вонючий код в т.ч. запросов. Если рассуждать по такой логике, надо идти работать сутенером или продавцом оружия. Очень выгодная профессия.
proger2011: Привел бы в пример страниц 50 кода, где можно выделить думаю штук 15 вьюшек с реюзом раз по 5 минимум. Но сами понимаете, конфиг показать не могу.
2Mort: На счет СКД. Я скажу больше - для 1сника .net или java окружение покажется вообще пустыней. Вобщем то чтобы собрать автомобиль иногда приходится отливать болты и работать напильником. Смотря что с чем сравнивать и какие задачи решать. Да, 1с как многие ERP дает много готовых удобных инструментов. Не надо понимать мой пост в том плане что 1С вообще ерунда. Просто меня удивило отсутствие такого элементарного инструмента, который хоть на каком уровне потребовал бы минимальных затрат на имплементацию. Если СУБД не поддерживает вьюхи, inline развернуть вьюху в селект непосредственно до отправки в СУБД - элементарная задача.

Когда уже 8-чные НЕДОзапросы приблязтся к T-SQL хотя бы в рамках 1cpp

Еще на счет того, где это нужно. Возможно стандартные конфигурации с небольшими докрутками и не требуют вьюшек, т.к. в них и так можно легко получить все, что нужно. Я говорю про самописную практически с нуля конфигурацию. Просто я, как разработчик в т.ч. СУБД не могу себе представить как можно писать систему хотя бы на пару лет разработки и с интенсивной аналитической отчетностью без вьюшек

(25) это что?

(27) Это говорит об отсутствии у вас как минимум воображения.

(25)
Да тут полно дотнетчиков, так что вы так не возбуждайтесь.

Как раз сейчас имею дело с корпоративным ПО, которое ВСЁ построено на "вьюшках" и "хранимочках". Разработчик сидит через кабинет.

Самая безобидная фантазия, по поводу этого разработчика - это как он ползет по темному кровавому коридору, пытаясь дотянуться до светлого проема двери. И я закрываю эту дверь.

(31) Это только по блату, Россия ведь :)
(32) Да вы, батенька, поэт... :)

>>ползет по темному кровавому коридору
Стивен Кинг отдыхает :)

(0) Современные технологии позволяют строить дома без топора, автомобили без напильника. Получаются дома и автомобили не хуже чем с применением топоров и напильников :)

(0) Сижу и с вьющками в одной системе,  и в 1с, и в импорте - экспорте данных посредством SP и даже, о ужас, подключаю вьюхи во внешние источники данных. Проблем не вижу.

(25) "Привел бы в пример страниц 50 кода, где можно выделить думаю штук 15 вьюшек с реюзом раз по 5 минимум. Но сами понимаете, конфиг показать не могу. "

Привет архитекторам и разработчикам. Это явно из области гоvнокода.

А вот я не считаю платформу фекалиями (а на СКД вообще молиться готов), но тем не менее с (0) согласен. Механизм был бы очень полезен в ряде случаев.

(38) Дык напиши...

(0) в 1с++ активно юзаю вьшки при обмене с конфами на 8.x В прямых скулевых запросах в 1С 8 тоже юзаю вьшки.

Автора смущает что нет возможности поюзать их на уровне платформы, как я понял? :)

>> Нет уж, я уж лучше буду получать сколько получаю и никогда в жизни не видеть этот вонючий код в т.ч. запросов.

Это достойно мемори!

>> Заглянул давеча через плечо знакомого программиста на 1С
>> Привел бы в пример страниц 50 кода

Взаимоисключающие параграфы детектед.
http://demotivation.me/images/20081020/yzsrjctzes1y.jpg

(0) Заглянул давеча через плечо знакомого программиста на джаве. У вас нет регистра бухгалтерии? как же вы бедные работаете то без него????

(25) Беспредметный выброс фекалий.
Пока не будет конкретного примера, разговор ни о чем.

гы

что такое вьюшка - это некая функция возвращающая таблицу которая где то как то была подготовлена?

ну и чем это принципиально отличается функции возвращающей ТЗ?

.
а вьюшки на оракле, db2 и постгрии тоже есть?

кто автору мешает в сервеном манманте заменить таблицу на view

с учетом, что все последние версии субд , поддерживанмые 1с8,
имеют ddl триггеры, настроить при рестрктуризации автоматическую подмену table<->view -не проблема

и кстати,
чем оно отличается от обычного запроса?

Достали эти кодеры и фанаты низкоуровневых языков. Когда то давно повезло мне поработать с ораклистами криворукими. Точнее не работать с ними а снимать организацию с их самописки глючной на 1С. Так вот одной из фич их базы было то что при внесении оплаты эта сумма ни как не меняла конечное сальдо по контрагенту, т.е. триггер отсутствовал вообще. Они раз в месяц запускали пересчет итогов у себя в базе, РУКАМИ запускали, иногда забывали ...

(48)
wiki:Представление_(базы_данных)

(48) да ничем - это некий запрос лежащий на сервере и возвращающий таблицу
далее к этой таблице можно обращаться другими запросам

типа как глобальная "временная таблица" которая обновляется при каждом обращении к ней

в 1С решается в зависимости от задачи

пример: есть таблица счетов, есть таблица реализаций а есть критерий отбора "Связанные документы"
а можно сделать свой регистр сведений "СчетаОтгрузок"
а можно сделать свою функцию "ДатьСчетаОтгрузок" которая будет возвращать ТЗ и которую можно будет потом в любом запросе использовать

2(51) Почти все так, единственный минус, что например такую ТЗ сразу нельзя использовать в том же конструкторе запросов, чтобы заджойнить с другой, предположим физической таблицей документов...
ну вернее можно конечно, загнав во временную таблицу, н только сам конструктор не будет знать о наборе полей этой ТЗ

(51) Функция у тебя будет динамической, а вьюха будет скомпилирована, оптимизирована.. Но это не принципиально. Чего хочет достигнуть автор вьюхами, скорости, или там скрытия структуры хранения данных(хотя сами метаданные суть вьюхи в опр. смысле) - непонятно.

а вообще, виртуальные таблицы это же и есть вьюхи.. не ?

(55) да

2(55) виртуальные - да. автор хочет иметь возможность стряпать виртуальные сам. Описывать их где-то в метаданных и юзать потом в коснтрукторе запросов

(57) а зачем, уже хоть один пример зачем это было бы нужно в 1С приводили ?

view
d 1c нужны в 3 случаях

1) для динамического обновления структуры бд
  когда часть процессов работает со старыми данными а часть с новыми

2) для секционирования

3) для использования функционала, не имеющего аналогв в 1с

например пространственных индексов


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

(59) ыыыыыы

можно я повторю вопрос: для чего в 1С можно использовать вьюшки?
можно пример прикладной задачи?

(58) см (22)

(61) какой то бессмысленный смысл...

2(61) какой-бы подзапрос из любой типовой ты бы выделил во вьюху?

(60) Как простейший пример - я тысячу раз слышал вопли про километры запросов с временными таблицами в том же закрытии месяца. При наличии view можно было бы эти километры оформить в понятном структуированном виде.

Принципиально ничего не изменилось бы, отсутствие механизма в платформе именно таким макаром и обходится. Просто стало бы удобнее :)

(64) А ничего что там текст запроса динамический? В зависимости от параметров работает та или иная ветка в запросе

Или 20 въюх?
Если параметр1 тогда
результат=вьюшки1
ИначеЕсли параметр2 тогда
результат=вьюшки2
Иначае ...

2(64) м... А потом разработчики типовых меняют название реквизита с ВидНДС на УДАЛИТЬВидНДС...

(64) невижу ничего удобного...
вьюха она же хранится на уровне субд, то есть что должно произойти при необходимости изменить логику работы "вьюхи" ?

(59) как связаны вьюхи и секционирование?

(65-66) Вьюхи составные. И да, при наличии условий в логике - ВЫБОР КОГДА и и т.д.

(67) Переименование реквизита с ВидНДС на УдалитьВидНДС само собой предполагает, что этот реквизит более нигде не должен использоваться в прикладном коде.

(68) В пофигураторе ее редактируешь, при реструктуризации делается все, что должно делаться на уровне СУБД. Да и вьюхи, которые просит (0) вовсе необязательно должны быть вьюхами на уровне СУБД.

(71) что то типа агрегатов?

(60)

примеры для (59)

разжёвывать Вам не буду.

для (1) - поменялся тип с простого на составной и обратно

 в бд поля удалили, но пользователей выгонять нежелательно
 сответственно пересоздали  view, которая пердставляет отсутствующее поле, как NULL или его аналоги для   составного

для (2)  разместили оперативные итоги в отдельной таблице

для (3) пересечение интевалов
   учет расписаний
   попробуйте создать эффективный индекс классический

   для задачи

   выбрать все  интервалы,  поподающие в заданный интевал.

2(70) ну вообще да.. это я просто бурчу, что так происходит не всегда..

(72) Агрегаты тут каким боком то пробегали?
(74) Все мы на это бурчим :)

(75) тоже на уровне конфигуратора создаются.. по необходимости.. с заданными настройками..

так же предлагаешь с вьюшками работать?

(73) имхо за уши притянуто чтобы оправдать применение суперского инструмента там где он нахрен не нужен...

(76) Только они совсем для другого предназначены

(78) ну вообще то грубо говоря ровно для того же самого.. только сфера применения жестко ограничена

(32)Я говорю лишь про наличие инструмента, точнее его отсутствие. То, что у людей бывают кривые руки, этого никто не отменял. Кстати в этом плане 1С выигрывает, т.к. криворукий кодер не сможет сильно нагадить - ограничения платформы.
(37)Согласен полностью. Но имеется как данность.
(38)Я никогда так не выражался, просьба внимательнее читать посты
(43)1:1. А если серьезно - пишем любой софт для любого заказчика. С нуля писать конечно тяжко, зато любую задачу. На этом и живем. Кормимся на заказчиках, которым по тем или иным причинам не подходят коробочные решения.
(47)Я говорю про родной инструмент разработки платформы, а не какие то низкоуровневые костыли
(49)см выше ответ на 32
(54)(59)Возможно я не совсем понимаю доступные инструменты, но вот вам пример, который показывает преимущество вьюхи перед временной таблицей. Есть TABLE A(ID int PRIMARY KEY, name varchar) 100 млн записей. Делаем вьюху create view B select * from A left join ... (таблица с кучей джойнов). запрос: select name from B where ID = 10. Если делать через временные таблицы (функции, или что там еще), тогда во временную таблицу _физически_ закачается 100 млн записей да еще и с декартовым произведением по другим таблицам. Потом из всего этого мусора возьмется одна единственная запись. На вьюшках - это будет один запрос в _одну_ таблицу (т.к. выбирается только одно поле), который отработает мгновенно по primary key.
(60)Для того же, для чего их использует пряморукий разработчик БД - инкапсуляция, code reuse
(77)Если поддерживается SQL, почему бы не предоставить привычный набор инструментов? Никто не спорит, давайте вместо селектов продолжать писать for. Так в свое время писались системы на каком-нибудь DBase

Кроме упомянутых виртуальных и временных таблиц, и источников данных.
хотелось бы напомнить про критерии отбора(слабо), шаблоны в правах, и подсистему УПП "Настраиваемые отчеты".
последняя больше всего имхо соответсвует тому чтоискал топикстартер.

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

(63) я бы выделил шаблон "срезПслденихНаКаждуюДату" и сделал бы виртуальной таблицей

2(81) я хотел упомянуть и критерии отбора и последовательности. Но и те и другие - реальные таблицы, а не виртуальные.

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

(80) Я прошу прощения, но что за бред? Какие 100 млн во временную таблицу? А сделать источник не через вьюху, а через подзапрос как источник что мешает? Или все условия только во WHERE должны лежать для всего запроса?

(80) Если делать через временные таблицы (функции, или что там еще), тогда во временную таблицу _физически_ закачается 100 млн записей да еще и с декартовым произведением по другим таблицам.


ну ну. мат часть поизучай

(27) "Просто я, как разработчик в т.ч. СУБД не могу себе представить как можно писать систему хотя бы на пару лет разработки и с интенсивной аналитической отчетностью без вьюшек"

то, что Вы будете писать пару лет вьюшками, 1Снег напишет за неделю по вечерам без них :)

по поводу где применять вьюхи.
имхо часто встречается ситуация:
в систему добаляется справочник1(как-то связан со стандартными(Стандартные))
создается пара новых документов(завязаны на справочник1 и Стандартные)
в модуле проведения Запрос1( 3-5 временных таблиц), пара печатных форм(похожи на запрос1).

Начинаются хотелки заказчика - печатные формы (данные документа, данные документа + какая то инфа, данные документа сгруппированные по чему-то - то же Запрос1 вид сбоку)
хотелки №2 - итоговых отчетов парочка по проводкам документа за месяц(Запрос1 с другого боку).
бизнес меняется - что-то меняется в справочнике1 (в моей практике он часто становится регистром сведений).

Паттерн "че Вам сложно добавить простой документ, которого нет в ТЗ?"

(88) а причем тут вьюхи то?

(89) обычно запрос1 начинается с того что Справочник1 както соединяется хитро со Стандартные в первых временных таблицах. и эта связка идет через всю подсистему.

хуже жить без баб

(86)Минуточку. Матчасть я не знаю, гугл ничего детального не подсказывает. Конфигурации тестовой под рукой нет, но если рассуждать логически...

Насколько я понимаю с момента заполнения временной таблицы все изменения исходных таблиц уже не попадут во временную таблицу. А это означает что содержимое физически было скопировано. В момент копирования еще неизвестно с каким where вы будете делать селект по временной таблице, а значит надо копировать все. Также в этом варианте после физического копирования становятся неактуальными любые индексы по исходным таблицам, соответственно любой запрос из временной таблицы будет работать как full table scan. Разве что не повесишь индексы непосредственно на временную таблицу, но это уже другая тема.

Если же в селект из временной таблицы попадают все изменения оригинальных таблиц, так это и есть вьюха, т.е. запоминается только селект, а не данные.

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

Я все-таки подозреваю что реализован именно первый вариант. Конструкция очень похожа на select ... into temp_table какого-нибудь оракла или MS SQL. А там временные таблицы работают именно по схеме, описанной в первом варианте.

(85)Речь не идет о принципиальную невозможность выполнить такую задачу. Речь о том, чтобы не копипастить этот подзапрос в over 9000 других запросов, где он нужен. А один раз сохранить его в метаданных с неким человеческим именем. Кроме code reuse также значительно улучшится читабельность запросов. В идеале на самом верхнем уровне будет SQL который образно-говоря сможет прочитать любой бухгалтер.
А вообще, вот тут много народу ругается на кривые руки кодеров, но не подозревают что это лечится применением правильных стандартов разработки. code style, unit testing, code review, refactoring. Только не говорите мне что в 1С это все не применимо. Качественный код залог спокойствия разработчика при любом капризе заказчика. И мой пост как раз и ведет речь про качество кода.

(92) во временную таблицу попадут данные соответствующие select name from B where ID = 10. а никакие 100 млн записей

(93) О стандартах разработки слышали в основном те программисты 1С, которые перешли на 1С с других технологий (делфи, си++). Подавляющее большинство программистов 1С зарабатывающих 100К в Москве не знают смысл слова рефакторинг и имя Мартина Фаулера ничего им не говорит.

(0) пошел под лавку быстренько... иди на рсдн, если такой правильный...

(93) В мире 1С важнее умение общаться с пользователем и быстро делать его хотелки. На качество кода, в большинстве случаев, забивают. Главное чтобы работало. А то, что Имена директоров, айпи адреса, домены вбиты константами в код руководителей отделов не волнует. Они считают это нормой.

Когда я пишу
Выбрать Владелец.ОсновнойБагклвскийСчет.Банк.Код из Справочник.Договоры

Я же не джоню к таблице контрагентов, банковские счета

Чем это отличается от въюх ваших?

(94)Пруф?
Попробовал погуглить. http://aitika.ru/otvety/2472-1c-Nemnogo-teorii-Vremennie-tablitsi
"Временные таблицы 1С - это локальные временные таблицы SQL, со всеми их последствиями"
Временные таблицы MS SQL - работа по описанному в комменте (92) варианту 1. Т.е. скопируется 100 млн записей в момент вызова select ... into temp_table. когда делаешь select * from temp_table, в ней уже лежит 100 млн записей без всяких индексов (другими словами практически любой запрос будет работать по full table scan, т.е. перебирать все 100 млн записей). Кстати там же чел пишет что индексы на 1с временные таблицы повесить нельзя.

давеча глянул платежную ведомость на зарплату местного прога.. он на яве и си чото пишет... и задался вопросом:

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

непонятно.. ну вообще непонятно...

(93) повторяющихся подзапросов, которые можно было бы выделить в отдельную параметризированную сущность в 1С не очень много, в (82) наверно самый частоиспользуемый пример того, что можно было бы выделить во вьюху, но и этот пример используется не на столько часто, чтобы приходилось "over 9000 других запросов" писать на его основе. Т.е. получается, самые частоиспользуемые вьюхи реализованы в 1С и называются виртуальными таблицами, а остальное все мелочи - даже и пример из (82), для написания которых знающие люди просто потратят лишние 5 минут чтобы описать эту Вашу вьюху с помощью языка запросов 1С.
Если же речь идет о потерях производительности, то эти проблемы так же вполне себе решаются и в 1С, причем зачастую средствами самой 1С.

(98) Замечательно что так можно писать. У вьюх есть применение не только в виде джойнов, но еще и всякие вычисления. Например в тех 50 страницах кода, которые я пролистал по pgdn я увидел кучу "выбрать-если".

(100) может он опыт накапливает и готовиться к прыжку?)

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

типа как ООП - ненужно оно, как бы адепты истинных языков не распинались на тему крутости ООП - вот просто он излишен и в "мире 1с" не нужен.

так же и с вьюхами - как только на уровне платформы они будут нужны - они появятся на уровне платформы.

(92) Вот сколько умных слов тут понаписано - и рефакторинг, и стандарты разработки и пр..., но лучше, имхо, начать с принципов работы бд.
(99) ха-ха-ха-ха! Ну возьми профайлер, посмотри, что происходит при запросе сальдо к счету, хотя бы.

(99) автор этой статейки лучше бы почитал про параметры вирт. таблиц.  не надо гуглить все написано здесь. http://technet.microsoft.com

(105)
1. Имеется в виду как строятся планы запросы и чем отличается table scan от clustered index seek? Да, полезно знать. Но кстати стандарты разработки применимы к любой платформе. В т.ч. к написанию скриптов SQL.
2. Когда гуглил, заметил я что есть некий механизм в 1с. Вроде бы он называется виртуальные таблицы. Но задача в том, чтобы самому эти виртуальные таблицы создавать и добавлять в конфигурацию. Насколько я понимаю их создавать нельзя.

*Но задача в том, чтобы самому эти виртуальные таблицы создавать и добавлять в конфигурацию. Насколько я понимаю их создавать нельзя.

Нет, нельзя.

(107) Так же нельзя кофе сварить с помощью 1С. И пиво она из холодильника не носит

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

(110) у меня сложилось впечатление что автор хочет использовать 1с для вычислений, при которых всегда нужны актуальные данные.
Но 1с не предназначена для этого. У нее своя ниша использования.

(107) Нет, имеется в виду конкретное незнание предмета. Даже в таком простом аксепте, как использование временных таблиц. Вот объясни, зачем пихать "во временную таблицу" данные, которые у тебя хранятся где-то ещё, в полном объеме? Не проще ли тогда взять их из реальной таблицы, чтобы TempDB не треснул?...

(111) в таблицах 1с хранятся не актуальные данные?

2(111) серьезно? даже если в запросе буду использовать ДЛЯ ИЗМЕНЕНИЯ, и накладывать блокировку?

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

(115) Обращение к вьюшке - это исполнение запроса:)

(104)Железная логика. Просто по истории развития 1c видно, что платформа постепенно вбирает в себя элементы классических сред разработки
(110)Узнал я про вьюшки лет 8 назад. А идея моего поста заключалась в том чтобы заставить задуматься об удобности инструментов. На моем личном опыте много раз бывало так, что я открываю для себя некий фреймворк или паттерн и сразу "Ух ты, как круто, как же я раньше без этого жил".
(112)Не нужно конечно. Но вьюшками решается задача инкапсуляции и code reuse без последствий вроде копирования 100млн записей и full table scan.
Ладно, мы уже уходим от темы. Думаю я уже достаточно написал чтобы выразить свою мысль. Если действительно есть аналог вьюшек, просьба написать конкретный пример (а не раскидывать панты), из которого будет видно что:
1. селект пишется один раз и реюзается в конфигурации в любом месте
2. 100млн записей не копируется, все селекты работают по индексам исходных таблиц
Думаю эта задача под силу человеку, который знаком и с 1с и с СУБД (т.е. может отличить full table scan от clustered index seed)

(115) у меня для него плохие новости. во вьюшках не хранятся данные. и брать их оттуда не получиться.

(115)
Ого, да тут всё по серьезному.

ну значит я про вьюшки мало знаю просто :)

(117)(3) Внешние источники данных не устраивают?

(117)
"На моем личном опыте много раз бывало так, что я открываю для себя некий фреймворк или паттерн и сразу "Ух ты, как круто, как же я раньше без этого жил".

Можно последние три случая?

(121) их с таблицами базы джойнить нельзя. не удобно.

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

(117)
"Но вьюшками решается задача инкапсуляции".

1С-ник эту "задачу" решает на этапе проектирования.

То, что ты называешь вьюхами - 1С строит из прикладных объектов, и как показывает практика - намного более успешно.

Вьюх у тебя в базе может быть 1500 штук - офигенная инкапсуляция.
По названиям их различать?

И вообще - бизнес-логику описывать на языке T-SQL - это как с рогаткой на стадо динозавров. В какой-то момент это может показаться успешной идеей.

(123) Ну он же говорит не об обращении к метаданным, а об обращении к базе...

(125) Ну, что самое интересное - что ты в MSSQL напишешь функцию, что в 1с напишешь(кто бы мог подумать!) -  функцию!:)

(124)
"На этих словах сполз под стол."

То есть - реализация  одного отчета должна зависеть от реализации другого?

(128)  какая новость, правда ? Мы хотим расшифровать остаток товара движениями за месяц, у нас есть уже отчет по движениям, но мы заново его рисуем внутри вложенной схемы, потому что разработчики не позаботились о возможности повторного использования кода.
То же самое и с километровыми запросами, одни и те же куски можно было бы использовать в разных местах, ан нет, приходится копипастить

(124) Ну... что тут сказать... Не хочешь - не юзай. В том понимании, в котором вьюшки используются в MSSQL, у меня используются внешние источники данных(что интересно, внутри них я как раз юзаю вьюшки:)).

(129)
Спуститесь на землю, товарищ.

(0) ещё один не вкурил суть 1С...

(130) а чего там 1c у нас пишет про доступ к данным не через движок платформы? Да и правильно, впринципе пишет, у нас тут какбэ трехзвенка, никто тебе не станет гарантировать что твоя вьюха вернет то что ты ожидаешь

(131) яж написал что сполз под стол ;) куда ж еще ниже спускаться ;)

(129) Посмотри бух. отчеты, там без вложенных схем данные расшифровываются другими отчетами, тоже самое с километровыми запросами, все они у нормальных людей в общих модулях...

Скука.

Я понимаю - про делегатов потерли бы, про LINQ, да многопоточный...
Уж про интерфейсы XAML-овские молчу - надоели кнопки да гриды..

Нет, вьюхи им подавай.))))))))))

(133) Да ты че?:) А "внешние источники данных" у нас уже не часть конфигурации?:)
Ну, я шучу, конечно, разговор шел о отсутствии вьюшек в 1с. Они есть, механизм их использования есть(имхо, несколько более заморочено, чем в MSSQL напрямую, но да ладно). Если же говорить о вьюшках с использованием метаданных - имхо, юзай функции и внешние обработки.

(135) да, 2-3 страницы овнокода на отчет и не надо никаких вьюшек, баловство это все

(136) Линкью - гадость... Каждый раз плююсь, когда на нем пишу:):)

(136)+
Забыл еще correlation subquery - вот этого реально не хватает.

(139)
Может быть, в каких-то моментах он неочевиден. Какая альтенатива?

(137) в качестве внешнего источника никак не поюзать данные своей же конфы. Просвети пожалуйста про механизм 1с. В конфе тут и там используются данные из периодического рс. (Точнее их несколько)Каждый раз надо втыкать запрос с параметрами виртуальной таблицы, утомляет. А тут еще назревает изменение, при котором надо будет эти параметры поменять, это теперь по вей конфе шерстить запросы и снова копипастить.

(140) 1. Прямо вот наступил на больную мозоль.:):) Да, очень не хватает.
2. Циклы:)
(141) Это почему? Юзать - можно, через ту же вьюху, по поводу параметризации - да, такой механизм здесь не предсмотрен - ну и юзай функцию(функцию 1с). Реально, конечно, можно приколоться и пересоздавать вьюхи "на ходу", но это уже изврат.

(140) кстати да, тоже приходится извращаться на эту тему ;)
Ответ опять: скд , но там опять борода  с невозможностью прицепить более одного источника данных.
В общем по всем раскладам надо ждать допила скд.

И да, вьюхи таки есть, от части: дополнительные характеристики у объекта метаданных, тоже сделаны только на половину ;) сыра еще 8 ка, надо было на 77 сидеть.

(0) а что ты на форуме 1С делаешь уже спрашивали?

(145) да по сути он прав, но извини что продублировал

(140) да просто можно было ввести нормальный транслятор для любой субд и допиливать файловый вариант в сторонке, тем более по сути он и не нужен

(145) ему даже не предлагали прострелить себе коленку....

(149) думаешь лн бук держит на коленке, когда сюда пишет?

лн = он

(150)ну не хреном-же он его поддерживает...

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

оно конечно, во временных таблицах данные конечно устарели, а во вьюшках (тьфу ты господя) вечно молоды...

что временные что вью работают абсолютно одинаково

(155) а время на создание временных?

господа, часом временные с виртуальными не путаете?

(23) "В СКД не всё можно реализовать для нормального вывода отчета :) на деле, почти и не пользуемся в своих конфах...."

Вкладку Макеты смотрел?

(156) а время вьюва вьювов ?

(158)не, есть случаи когда реально проще ручками.... наприемр когда форма очень сложная и по нескольку раз прибегают юзера то так поправь то этак...

+ временные не создаются в базе до поры и времени

Вспомнился анекдот про (0)
"-А ты зачем, противный, в наш форум ходишь?"

(159) насколько я помню логику вьюшки кэшируются как-то, или  неправ?

Мне кажется, вьюхи привели бы к усложнению читаемости кода.
Так вы хотя бы глядите на 50-страничный запрос и можете "читать его с листа", все таблицы которые там учавствуют имеют понятный вам смысл.

При активном использовании вьюх в УПП было бы несколько сотен (!) вьюх с похожими малопонятными именами, запомнить их было бы сложно, сами запросы стали бы короче но менее понятны.

Короче то же самое что с классами - код стал бы лучше и короче, но куда менее понятен

(164) так, стоп, отвлечемся ... а что там с классами?

(165) классы приводят к появлению сложных библиотек и очень высокоабстрактного кода.
Если не знаешь наизусть библиотеку - в такой код лучше и не соваться

(163) прав, но и времянки не всегда присутствуют на диске, даже если они в работе

(0) зависть - плохое чувство

+ как будут выглядеть вьюшки для файлового варианта ?

(0) Причин много.
Сложнее было бы поддерживать портируемость между разными СУБД (1С отказалась от хранимок даже в системной реализации) и прозрачность связки 1С-СУБД.
К тому же вьюшки и хранимки (и не дай бог элементы полноценного ООП) позволили бы реализовывать дополнительные уровни абстракции, что противоречит базовой концепции 1С "доступно и всерьез" и ограничивает сложность прикладного решения "одним шагом" от базовой объектной модели.
А ведь именно эта концепция, как не крути, обеспечивает массовость успеха 1С.

(100) Средний франчевый одноэсник результата за неделю выдает на порядок больше чем вебер за месяц

(100) Залез на хедхантер, в вакансиях программистов Ява и С++ ценник намного выше, чем у одинэсников.

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

(27) Ну и чьи это проблемы, что не можешь? Учись!

(70) Не предполагает. Как минимум, при обновлении ИБ возможно обращение к этому реквизиту для переноса данных из него в новое место.

(80) Что мешает из таблицы A во временную таблицу выбрать запись с ID = 10 и только потом соединять ее (а если надо только name - то вообще не соединять)? Что лучше выбрать 1 запись из 100 млн. записей таблицы A или из 1 млрд. записей таблицы B? Я при этом уже не говорю о том, что обновление таблицы B - это большие накладные расходы и распухание базы в разы.

(129) Зато все в одном месте.

(143) 1С как-то цепляет. В том же расчетном листке, например.

(156) Уж лучше чел подождет формирования отчета, чем куча людей не сможет вносить данные из-за постоянных блокировок, связанных с обновлением кучи вьюшек. Которые, может, нужны раз в 100 лет.

понаписали то... а кстати, RLS не вьюхи ли?

(0) без въюшек еще как-то обходимся, а вот без хранимых процедур хреново :)

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

Вьюшки не помешали бы, полезная вещь.

(0)(178) См. (173)

зачем в базу засунули пустые ссылки и неопределено?

(172) уровень подготовки сравни С++ и 1С

(90) Ерунда какая-то. Честно.

(107) А зачем самому создавать виртуальные таблицы. Пример можно?

(172) LOL

(0) Автору. А можно все-таки хоть один пример использования вьюх, не связанный с использованием шаблонов?

+(185) Про выборку 1 000 000 000 000 000 записей, когда нужно три записи, не говорить.
Уже разобрались, что это просто незнание того, что так тщательно обкакиваешь.

(12) Г@вно там, а не конструктор запросов.

(172) Зависит от опыта и знаний. Чистый ява-кодер стоит мало. Если добавить структуры данных, паттерны, фреймфорки, субд, знание предметки - то будет весьма приличная сумма.

(180) Пустые ссылки - что б поиск работал быстрее.
Неопределено, скорее всего для того-же.
Искать то, чего нет, намного дольше чем что-то.

(12) где? покаж скрин

(17) а с вьюхами, которые были бы вместо этого - не упрел бы? тут правильно заметили - дело в ГСМ архитекторов

(189) а зачем его искать?

(189) тма не для поиска, а что-бы как-то обозначить что каких-то данных нема. Например при левом соединении в правой таблице не данные а дырка от бублика

(172) можно количество вакансий и  средний уровень ЗП ?

имхо у меня есть пара знакомых на яве кодят.. пару раз спрашивал - по количеству вакансий и средней ЗП - отстой...

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

(193) я и так могу это определить, а иногда мне наоборот этого различать не надо

(0) Он бы еще спросил...загадочно, А КАК ВЫ ЖИВЕТЕ БЕЗ АССЕМБЛЕРА????

(190) в MSSMS в окне нового запроса, правой кнопкой Design Query in Editor

(197) он уныл... там даже WHERE нету

(198)+ не говоря уже о группировках, ROLLUPах, пакетах и прочем... а если и есть - то неинтйитивно

200

(198) там много че есть. надо пользоваться уметь. но я им никогда не пользуюсь почему то.

(201) если что-то не удобно - этим не пользуются, да. в этом конструкторе удобнее писать руками. в конструкторе 1с при переходе с 7.7 на 8.0 освоился минут за 10, на всякие темы типа построителя/СКД ушло еще пол часика

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

(122)unit testing+JUnit/NUnit, Spring framework, Apache Mockito
Да, в моем посте была небольшая подколка. Но я думал что она подзадорит знатоков раскопать технические детали и написать исчерпывающий ответ, мол ты ничего не понимаешь, все на самом деле есть и делать надо вот так. Такие посты встречаются. Хотя так никто и не написал есть ли аналог. Надо полагать что все-таки нет. Но большинство постов - нелепые попытки помериться писюнами. Еще ни на одном техническом форуме я не встречал столько людей с ЧСВ.
Вобщем всем пока. Пошел дальше творить чистыйидеальныйсовершенныйкодjava

(0)Собсна они там есть . Там есть все что предоставляет функционал СУБД. Есть желание - юзайте.   Создавайте вьюхи , табличные функции  и т.д.

Кроме "СрезПоследнихНаКаждуюДату" и "ОстаткиТоваровНаКаждыйДень" тоже ничего в голову не приходит. Да и в этих случаях под каждый отчет будет уникальный запрос со своими отборами/группировками.

(0) Прекрасно!

PS: Автор любитель пукать и невежа!

+(205) Например для аудита всегда можно наваять вьюшку   и выгружать своды проводок куда то . В Ехель и прочее , а когда Ехеля просто не хватит  в  таблику. Масса других примеров. Могу сказать штаааа заказчику абсолютно параллельно как эти данные получены.  Эксплуатация 1С  ,особенно вещей объемных , многопользовательских  не ограничивается
"монстроидальные селекты для отчетов на многие страницы ". Это быстро надоедает :)

(194) Цифры огласи. У меня приятель пишет на джаве (спб). В 26 лет зп 80, дмс, обучение, тренинги и пр. На лето в Европу ездит,с заказчиком общается. Есть пхписты с ЗП не намного меньшей. Им не приходится общаться с тупыми юзерами.

ВТ это не вьюха разве? В чем разница?

(204) клевый вброс, модераторы уже раскрыли, кто и старожил это был?

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

А пукнул он хорошо, эт да :)

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

Кроме того вьюха - это тот же скомпилированный запрос. Монстроидальный на много страниц. И пофиг где его написать - в самом отчете или на сервере.

(204) Насчет "чистыйидеальныйсовершенныйкодjava" очень слабо верится :) Скорее такая же фигня как у авторов нетленок (они тоже свой код считают за чистыйидеальныйсовершенныйкод1С).

(52) Если таблица с простыми типами - можно явно типизировать поля временной через "выразить" и с конструктором не будет осложнений

(99) Индексы на временные таблицы в 1С навешиваются запросто. Я бы не стал доверять твоему источнику информации.

(0)(204) еще раз апну. см. (173). Движение есть в этом направлении. Когда пришел на 1С - тоже удивился. Вроде бы очевидная вещь, ан нету. Не говорю уже про функции и хранимые. Особенно функции - тыщу раз писать одно и то же ...

(217)
Да, в 1С функций писать нельзя. Бывает неудобно.

Да, иногда с тоской вспоминешь семерку, где все это было...

(0)если нет больших объемов, без вьюшек можно и обойтись
если есть то можно сделать в скуле и поднять в ёксель

(212) Да многое, но не всё.. К сожалению, поддерживаемый mssql уровень изоляции транзакций не позволяет "drop database" при одновременном доступе.. :)