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

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

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

(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" при одновременном доступе.. :)