Про 1С++ООП, на ночь глядя бесстыжими вочами

[Пиит]

...беру это МножествоОбъектов, загружаю в ПЗУ...

В этом месте случилась описка, конечно здесь подразумевалось ОЗУ.

Что касается ПЗУ. Имхо не принципиально, каким из логических способов реализовано хранение данных. Будь они реляционными таблицами, иерархическими структурами или сущностями других заковыристых топологий -  это не имеет ровным счётом никакого значения. Я напомню, что все вышеуказанные структуры с помощью единиц и нулей располагются в одном и том же одномерном массиве под названиме ПЗУ. Они просто представляют собой более абстрактный, оторванный от железа и внятный для прочтения уровень интерпретации данных. Соответственно, и не принципиально использование той или иной из известных СУБД для свох целей. Нынешние СУБД - это системы управления данными низкого уровня, и дай им Бог здоровья.

Когда-то и программы Программисты писали Машинными кодами, и знание Ассемблера не освобождало от необходимости держать в памяти хренову тучу процессорных инструкций, номеров прерываний, адресов памяти и даже таблицу символов. Но ведь не зря на смену языкам низкого уровня пришли вскоре другие языки, которые так и назвали, в противовес Ассемблерам, языками "высокого" уровня абстракции. Это известные нам Си, Паскаль и другие. Так Программист перестал вникать в подробности очередного детища Intel, оторвался от железа, разгрузил своё ПЗУ и рабочее время, и тем самым получил возможность уделять больше внимания предметной области для решения своих задач.
Концепция ООП принесла в мир ИТ понятие Интерфейса. Это тоже своего рода революция, концептуальная и самодостаточная. Многие связывают появление ООП с Окнами, но это совсем не так. Интерфейсы были и раньше, только назывались они ВнешнимиБиблиотеками, СистемамиПредписаний и т.п. и были оторваны от своих СтруктурДанных. И ООП представился как следующий уровень абстракции программирования, ещё более высокий, чем те "высокие" языки. И назрел этот уровень абстракции исходя из элементарной необходимости неповторения кода, его инкапсуляции. Это основная причина революции, как сказал бы дедушка Ленин, "низы не хотели жить по-старому". Но это всё про ОЗУ.

Так до каких пор мы ещё будем зубрить названия колонок и индексов, и вникать в отличия ID от RowID? Не пора ли абстрагироваться от Таблиц в другие Измерения, в Объектную Модель Данных? Модель, где две абсолютно одинаковые Таблицы буду представлять собой совершенно разничные ПрикладныеКлассы, каждый со своим ПрикладнымИнтерфейсом. СтруктурыДанных придуманы ведь не просто так. Большинство из них представляют собой один и тот же ОдносвязныйСписок, но благодаря разным СистемамПредписаний, т.е. различным Интерфейсам, они представляются уже конкретными инструментами для решения своих прикладных задач.

Сейчас мы являемся свидетелями новой технической революции, и дело здесь не в ИИ. Имхо, если нет интеллекта естественного, не поможет и искусственный.
Архиважно то, что скорости работы ПЗУ и ОЗУ уже не отличается на несколько порядков, в тысячи раз, как на заре компьютерной эпохи. Теперь их скорости уже практически сопоставимы, и недалёк тот день, когда эти два понятия, бывшие когда-то разделёнными по объективным техническим причинам, сольются в одну сущность - ЗУ. И Машина станет работать по-другому, не по полувековому принципу - Из_ПЗУ_В_ОЗУ_И_Обратно, а В_Режиме_Реального_Времени, и любая программа будет запускаться не с белого листа, а в уже существующем Пространстве Данных, или Виртуальном Мире, как вам больше нравится...

[Пиит]

....Так до каких пор мы ещё будем зубрить названия колонок и индексов...

Несколько слов об SQL.
Своему рождению, как и многие мировые изобретения, структурированный язык запросов обязан обычной человеческой лени. Запарились однажды мериканьские программисты каждый день рожать новые отчеты своим бухгалтерам, и задумались, как им освободить по-больше времени для чаепития в полуденную сиесту.
Да, да, SQL был задуман не как средство программирования, а как интрумент пользователя, точнее сказать, продвинутого юзера. И те программисты здраво порешили, что вручив такую цацку юзеру, избавятся от него таким образом. Но, как это обычно бывает, что-то пошло не так.

Я учился в школе по учебнику Кушнеренко. Учебная программа того времени предполагала, что из любого школьника можно воспитать программиста, поэтому и упор в учебнике был сделан на изучение алгоритмов, абстрактного языка, двоичных систем и всего-всего очень скучного не только для девочек.
Но уже к концу 90-х содержание программ резко изменили. Оказалось, что стране нужны грамотные пользователи, а не программисты, и учебник сменили на более другой. И стали изучать школьники конкретно Паинт, Ворд, Эксель и всю эту прикладную херомантию.

Примерно так было и на Западном направлении. В условия быстрого роста рынка программного обеспечения рынок труда требовал потребителей, а не разработчиков. Не справились юзеры с такой цацкой, посему SQL и потерял первоначальное предназначение, Но, с развитием клиент-серверных систем оказался востребован в контексте сетевой логики, для транзакций не только на чтение, но и на запись данных. Таким образом, сей декларативный язык стал развиваться в сторону своей субэдэшной специализации, отдалившись на парсеки от замысла своих Творцов. К тому же, сиих Творцов купила с потрохами известная компания IBM, и кропели они уже над внереляционными вопросами, например как обойти конкурентов и т.п.

SQL тоже займёт почётное место в музее ПО всех времён и народов, но сейчас и без него не обойтись. Пусть он тоже работает на благо Отечества, но, как я уже говорил, на более низком уровне. На более высоком уровне Машина должна использовать его для реализации ПрикладныхКлассов. Даже Спр.ВыбратьЭлементы() имхо это не что иное, как Запрос. Только Одинэснику и знать о том не надо, он должен думать о том, что Спр - это Множество Элементов, а Спр.ВыбратьЭлементы() - это Подмножество указанного Спр, и каким должно быть это Подмножество, должен в полной мере нам рассказать Интерфейс БазовогоКласса.

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

[Пиит]

... любая программа будет запускаться не с белого листа, а в уже существующем Пространстве Данных, или Виртуальном Мире...

Надо уже закрыть этот вопрос, и больше к нему не возвращаться.
Окна задумывались как псевдомногозадачная ОС, и до сих пор она по сути таковой и является, с добровольно-принудительным последовательно-параллельным распределением между приложениями процессорного времени и ОЗУ. По мере роста количества процессорных ядер и соответсвенно возможностей физического распараллеливания приложений, Окна трансформируются в настоящую многозадачную ОС. Ну и флаг им в руки, развитие этой концепции мне не представляется интересным.
В контексте объединения ОЗУ и ПЗУ имхо более интересным мне видится ОС с общим ЗУ для всех исполняемых приложений. Таким образом, в одной такой ЗУ-ООБД смогут одновременно сосуществовать и 1Сv25, и Компас-33D, и даже Флинн Таггарт в таком Мире будет иметь право на дополнительную Жизнь. И в такой Операционной Системе в добровольно-принудительном порядке, может быть осуществлён универсальный доступ приложений к данным друг друга, на основе общих Классов как универсальных СтруктурДанных в общей для всех среде исполнения.
Но это, "по расчисленью ФилософическихТаблиц, лет чрез пятьсот"...

[Злоп]

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

- так это же про 7.7.

[Пиит]

-  так это же про 7.7.

И да, и нет.
Все мы Родом из 7.7, но в контексте нынешнего безобразия под номером 8.3 многие специалисты пожимают плечами, глядя куда катится Компания.
Не нашлось таки у них нового ДядиФёдора...

[Пиит]

... Есть в семёрке такой замечательный Объект, Регистр назывется...

Дядя Фёдор знал не только ООП и SQL3, но кое что ещё.
Откуда в Платформе взялось слово "Регистр"? Открываем толмуд по бух.учету и читаем: "Счёт - это учётный регистр, предназначенный для тэго вэго". Вот и весь секрет. Когда ДядяФёдор приступил к моделированию компоненты БухУчёт, он не поленился полистать специализированную литературу. Как известно, Счета бывают синтетические, т.е. группы, и аналитические, так называемые СубСчета. Но есть ещё и другие Регистры - аналитические СубСчета СубСчетов, которые в теории бух.учёта Кодируются специальным образом, но собственного названия почему-то не имеют. СубСчет же по латыни звучит как СубКонто, и в результате такой игры слов Компания являет Миру новый термин для обозначения этих Измерений. Красиво? Мне нравится.

В то время основная проблема учётных систем заключалась в замедлении расчета конечных итогов в процессе накопления информации. В контексте и бух. и опер. учета программы того времени рассчитывали конечные сальды начиная с первой проводки в системе, таким образом, чем больше движений, тем больше требуется времени для расчёта итогов. Многие специалисты находили выход в постоянном архивировании предыдущих периодов с перерасчетом входящих остатков в новый период. В V6 также была реализована подобная схема, но чуть хитрее. Была внедрена специальная Таблица, Бухгалтерские Итоги, а для смены ПериодаБИ требовалась соответсвующая процедура перерасчета Бухгалтерских Итогов. Шарик был доволен, его ноу-хау было немножко интереснее, чем у конкурентов.

ДядяФёдор так не считал. Принимая Счет и ВидыСубконто как измерения в многомерном массиве бухлалтерских данных, он задумал и реализовал в V7 самый что ни на есть настоящий OLAP-куб. Это и есть те самые Таблицы БухгалтерскихИтогов, которые содержат промежуточные данные бухгалтерских функций, ещё и в помесячном разрезе.
Знал ли ДядяФёдор в то время, что такое OLAP? Термин этот ввёл в обиход Эдгар Кодд в 93 году в известной статье  «12 правил аналитической обработки в реальном времени». Такие массивы использовались и раньше, с 70-х годов, а великодушный Эдгар в вышеуказанной заметке только дал добро на их применение в свой модели РБД.
ДядяФёдор мог и самостоятельно додуматься до подобной конструкции, а затем уже "включить диалап", чтобы удостовериться, что он не псих. Как бы то ни было, компонента получилась удачной. Положив структуру Таблицы Проводок в соответсвии с Таблицами БухгалтерскихИтогов, ДядяФёдор не только реализовал христоматийный ROLAP-куб, но и виртуальный одноимённый ПрикладнойОбъект, как технологию, объединяющую данные вторичных таблиц с исходными данными. И о приемственности Творец не забыл, и назвал такой механизм БухгалтерскимиИтогами.

В технологии OLAP, Таблицы, вмещающие в себе множества значений измерений общего массива данных, называют агРегированными, а уникальный набор значений, Кортеж данных в в этом многомерном Пространстве, в нашем случае это есть структура [Счет, Субконто1,.., СубконтоN], называют агРегатом, что вполне созвучно слову Регистр. Таким образом, ДядяФёдор и остановился на этом названии своей конструкции, с одной стороны, имеющем бухгалтерские корни, а с другой, вполне вписывающийся в актуальные по тем временам технологии.

Так в компоненте ОперативныйУчёт появился Регистр собственный, как таблица Многомерного массива, произвольный OLAP-куб, с неограниченным количеством как Измерений, так и Ресурсов. Причём Куб здесь немного урезанный, в отличие от БухгалтерскихИтогов. Почему-то один и тот же Регистр не может быть одновременно Оборотным и Остаточным. Но, несмотря на это, ПрикладнойОбъект Регистр, как и БухгалтерскиеИтоги, представляет собой Класс, объединяющий ТаблицыДвижений и ТаблицыАктуальности в одно целое.

Что любопытно, каждый новый Счёт в ПланеСчетов автоматически порождает новый бухгалтерский Регистр, и Одинэсники с удовольствием используют таким образом забалансовые счета в своих корыстных целях. И только Пираты Карибского моря могут  в таких случаях обвинять Сапожников в извращениях, дескать, не проще ли использовать для этих целей сам Регистр. Нет, проще таки за балансом, а Регистр только в случаях, когда количество измерений выходит за рамки ПланаСчетов. Но всегда нужно помнить, что количество агРегатов в OLAP-кубе растёт в экспонециальной прогрессии при каждом новом измерении.
ПланСчетов же по сути есть множество Регистров, и заметьте, даже бухгалтер имеет полное право на порождения нового МногомерногоПространства для своих целей, а вот кладовщик таким правом не наделён.

А что же такое "агрегатные" типы данных в нашей Платформе? Согласно Описанию встроенного языка, в этом чудном списке присутствует не только агРегированные Таблицы типа Справочник и Документ, но такие Классы, как СписокЗначений, ФайловаяСистема и даже XBase, в общем всё то, что порождается с помощью СоздатьОбъект.
Но об этом таки нужно спросить у Шарика, который одним лохматым ухом слышал слово "агрегат" от ДядиФёдора, но понять замысел Творца как известно был не в состоянии...

[Пиит]

... появился Регистр собственный, как таблица Многомерного массива, произвольный OLAP-куб...

Всякий Регистр есть Пространство, но не всякое Пространство можно или нужно отнести к Регистрам.
Так, НепериодическийРегистрСведенийV8 являтся несостоятельным Регистром от слова совсем, но зато эту конструкцию можно использовать в качестве дискретной N-мерной Функции, с помощью которой можно задать множество полезной информации, такой как СодержаниеДрагметалловВТМЦ, НормыРасходаТопливаНаТягачИВидПолуприцепа, РасценкиКатегорийВодителейНаРаботыПоВидамТранспорта, СодержаниеВкусняшекВПродуктахПитания и т.д. и т.п. Когда речь идёт о действительно условно-постоянной информации, подобные КнигиОВкуснойИЗдоровойПище должны быть всегда под рукой. В типовых конфигурациях V7 такую информацию обычно раскладывали в ПодчинённыеСправочники, что не является правильным решением из-за асимметрии последних. И ТМЦ, и Драгметалл есть равнозначные Измерения, и пользователь, помимо информации о содержании всех драгметаллов в конкретном ТМЦ имеет полное право видеть и содержание конкретного драгметалла во всех ТМЦ.

ПериодическийРегистрСведенийV8 уже может быть Регистром, и подчиняться воле ХозяйственнойОперации, но это вовсе не обязательно. Так, например, НормыРаходаТоплива могут меняться со временем в связи с пробегом или другими обстоятельсвами, но из этого не следует, что нужно кровь из носу создавать для Регистрации этого события специальный ВидОперации, достаточно внести изменения в эти таблицы вручную. Наверное от слова "вручную" у некоторых товарисчей наверху прыщи на теле высыпают, иначе зачем они закрыли возможность править таким способом Регистры и даже Проводки? Понять эту логику без дедушки Фрейда крайне затруднительно.

Ближе к делу. Любое Пространство может стать Регистром при условии, что оно будет наделено ещё одним измерением, не совсем обычным, и называется оно - Время. Только Время даёт возможность положить в Регистр Событие, ту самый Точку Пространственно-ВременногоКонтинуума, ХозяйственнуюОперацию со своим собственным для этого случая Реквизитом ДатаОперации.
Это достаточное условие, но оно не является необходимым. Если нет Регистратора, то нет и Регистра, поэтому ПространствоВремя может существовать и само по себе, хотя в общем, я и не знаю, где будет востребована такая конструкция, ведь даже Флинн Таггарт не будет рад стоять на месте. Движение - это Жизнь.

Здесь я считаю небходимым пояснить разницу между Регистром и OLAP-кубом. Регистр - это таблица, пусть и "вторичных" Движений, но таки исходных данных для OLAP-куба. OLAP в общем случае не содержит Время в своих Измерениях, но в обязательном порядке содержит ПромежуточныеИтоги в разрезе ВременныхОтрезков. И здесь я считаю ОстаточныйРегистрV7 также несостоятельным решением, в отличие от ОборотногоРегистраV7 и БухгалтерскихИтогов. Специалисты знают недостатки ТочкиАктуальности при перепроведении отдалённым задним числом. Похоже, ДядяФёдор как раз на этом Объекте сдал свои дела, и РегистрV7 стал очередным не_до_разумением.

Важно, что Регистром не обязательно может быть только сложносочинённое Пространство. Любой ТипДанных, наделённый свойством Периодический, может стать Регистром. Я очень буду скучать по Объекту "Периодический", даже если меня тошнит от этого названия. Ведь это придумал ДядяФёдор - определить Время как Свойство, и это очень Логично. Время есть необычное Измерение, у него есть свои уникальные особенности, и добавить просто так Время в Пространство в Качестве рядового Измерения не позволит использовать его без надлежащего Интерфейса. Поэтому я, в честь ДядиФёдора, предлагаю восстановить Время в своих правах, и определить как фундаментальное Свойство любого ТипаДанных. Не вижу для этого никаких препятствий.
В системе, где каждый ТипДанных уложен в свою ТаблицуБД, и даже для Числа и Строки есть свои отдельные хранилища, добавить ещё одну колонку Время и ещё один индекс Owner+DateTime не составит никакого труда. Таблицу КонстантV7 видели? Вот, примерно так, каждый ТипДанных ака Класс, трах-тибидох, может одним щелчком превратиться в настоящий Регистр. И Зигмунд упаси запретить изменение его "вручную"...

[Злоп]

И почему это остаточный регистр бяка, а оборотный небяка?
.
Кстати, так до сих пор толком и не знаю что сидит в таблице итогов оборотного регистра (например, с периодичностью = месяц)...?

[Пиит]

.  И почему это остаточный регистр бяка, а оборотный небяка?...

Да, погорячился немного.
Спасибо, Че, так бы и не знал я, чего там в таблице сидит.
Вполне рабочий OLAP, в разрезе Дня, как и в оборотном.
А я был уверен, что там только оперативные итоги на дату актуальности.
Тогда тем более не догоняю, почему остатки и обороты не совмещены в одной таблице, с совмещением периодов OLAP как для сохранения остатков, так и расчета оборотов.

[Злоп]

В разрезе дня? В таблице ИТОГОВ оборотного регистра с периодичностью месяц?
.
Ещё раз вопрос: что сидит в таблице итогов оборотного регистра?
.
Или перефразируя вопрос - если так будет проще - как считается такое: ТА допустим в июне, запрос типа: "дай мне оборот по продажам за период с 15 января по 25 марта"..?

[Пиит]

...Ещё раз вопрос: что сидит в таблице итогов оборотного регистра?...

В таблицах итогов в качестве периода указывается Дата, таким образом, минимальным возможным периодом теоретически является День, а фактически Период устанавливается внешними параметрами Регистра. Так, для Оборотного Период задан в Метаданных, а для Остаточного - в режиме Предприятия как ПериодичностьСохраненияОстатков в УправленииОперативнымиИтогами, а значение Периода представляется как НачДата интервала, в который попадает Движение от Регистатора со своим ДатаДок.

Здесь имхо и кроется разгадка слова "Периодический" для Реквизитов с Историей. У Наследников ДядиФёдора возникла путаница между Временем в ТаблицеДвижений и Периодом в ТаблицеOLAP.
Историю Реквизита можно представить себе как вырожденное, 0-мерное ПространствоВремя, в котором есть только Время, но нет по факту других Измерений. И такую конструкцию, Движения Реквизита во Времени, можно назвать в общем случае Регистром, но я бы предложил конкретизировать такие Реквизиты названием Динамические. А Регистром таки называть ПрикладнойОбъект, для которого организован свой OLAP-куб.
Теоретически, и Динамический Реквизит может иметь свой OLAP-куб, но это уже имхо перебор на текущем этапе проектирования системы...

[Злоп]

Вопрос остался. Какие итоги сидят в таблице итогов оборотного регистра, например, с периодисностью месяц? Итог по обороту за месяц? Или итог по обороту за месяц нарастающим итогом от предыдущего месяца?

[Пиит]

...Или итог по обороту за месяц нарастающим итогом от предыдущего месяца?

По факту Обороты суммируются из Движений за один Период, без нарастающих.
А теоретически всё возможно. Даже возможно построение Вложенных друг в дуга OLAP-ов, с последовательным вложением Периодов друг в друга, например по Годам-Месяцам-Дням.

Я здесь уже вспоминал четырёхэтажные конструкции для обработки данных Автотехконтроля. Задача вспыла как экстренная, по результатам проверки предприятия профсоюзной организацией. Смешно, какие-то профсоюзы поломали учёт зарплаты об колено. Я посоветовал главбуху послать их нах, мол не Трудовая инспекция, и свои рекомендации пусть засунут себе в трубочку. Но руководство решило не выёживаться, и поставило меня раком - пересчитать за 2023 год всю зарплату, и доначислись водителям-дальнобойщикам помесячно Ночные, Праздничные и ДоплатуДоСреднегоЗаработка, перепечатав при этом все Табеля и Ведомости. А весь прикол в том, что данных по работе водителей взять неоткуда, зарплату надо начислять, даже когда они в рейсе, а полагаться на данные тахографа в оперативном режиме невозможно, поскольку сей прибор находится в рейсе вместе с водителем. А возомнившемуся инспектору все доводы были по барабану. Вот и пришлось утвердить в качестве данных объективного контроля Движение Автомобилей от службы Автотехконтроля. А данные представляют собой большую Таблицу всех Движений по каждому Авто, с записями на Дату от НачВремени до КонВремени, приходящиеся не только на текущие сутки, но и зачастую переходящие на следующие.
В общем, как говорят в таких случаях, упала на мою старую больную голову не детская такая головоломка. Но ничего, победил, разобрал, привязал к Сотрудникам, собрал, вычленил и Ночные, и Праздничные, и всю остальную херомантию, и за День, и за Месяц, и за Год. А для этого пришлось организовать вложенные OLAP-ы на ПодчиненённыхСправочниках.
В процессе решения нашёл для себя новые неведомые доселе законы Времени. Например, для Временных интервалов вполне правильным будет употребление значение 24:00:00 для КонИнтервала, не включая в сам Интервал последнее значение. Таким образом, проверка вхождения МоментаВремени в ИнтервалВремени будет выглядеть как ( >=00:00:00) И ( <24:00:00), что ликвидирует неопределённость момента смены Дня.
К слову, ИнтервалВремени может быть задан как Вектор, двуми значениями, НачИнтервала как ДатаВремя и ПротяжённостьИнтервала Как КоличествоВремени, по сути Число.
Жаль, что Интервалы как таковые вообще обделены вниманием в наших Платформах. Имхо, без таких ТиповДанных и возникают недопонимания и путаницы при решении прикладных задач...

[Пиит]

... У Наследников ДядиФёдора возникла путаница между Временем в ТаблицеДвижений и Периодом в ТаблицеOLAP....

Подобно Николаю Ивановичу Лобачевскому, Юрий Валентинович Кнорозов, сидя в своей тесной мастерской, вооружившись исключительно своим опытом, интуицией и здравым смыслом, сотворил чудо, недоступное для понимания наследникам индейцев Майя, и не только им. Представьте себе только, обычный русский парень взял и расшифровал потерянный древный язык и восстановил письменность, за что получил звание почётного Ацтека всех латиноамериканских времён и народов.

В последние годы, даже можно сказать десятилетия, я превратился из сухого математика в довольно живописного филолога. Скучно раскладывать Пространства на атомы, гораздо интереснее изучать живую Историю, как ПространственноВременную структуру, движения в которой осуществляют Великие Люди, в которой Геном играет не последнюю роль и загадки которой представляют гораздо больший интерес, чем лохматость какого-то прикладного приложения. История непрерывна, тянется с незапамятных Времён Бусовых, а мы видим сегодня только оперативные её итоги, а былое воспринимаем как что-то непостижимое и запутанное настолько, что и разбираться в нём порой и не желаем.
Сказать, что Историю пишут победители, это ничего не сказать. Я могу утверждать, что победители всегда переписывают Историю, и в этом их слабость. Недоверие к пишущим исторические трактаты вкупе с научныи подходом от Николая Ивановича представляет собой серьёзный скальпель, которым можно вскрыть многие опухоли Исторической науки. А если к вам на помощь придёт сам Александр Сергеевич, то поверьте, тогда точно нет ничего невозможного.

Хотите, друзья, я поведаю вам тайну царевича Дмитрия Угличского, младшего сына Ивана IV? И не только тайну его гибели, но и тайну его рождения. А заодно расскажу, кем на самом деле был самозванец Лжедмитрий, и какова настоящая История Смуты и причина последующего воцарения Романовых.
Не в этой ветке, в соседней. Предлагаю выше коротенький опрос.