символ конца эпохи имперских амбиций шведов, проиграв в той войне они сосредоточились на внутренних проблемах, а не завоеваниях Крымов, сейчас Швеция одна из лучших стран по уровню жизни при том что климатические условия далёкие от идеалов.
Сидел давно в трассировщике — на 1C V77, в начале века.
В 1C V8 подумывал про трассировщик — так как в начале освоения этой версии полагал, что язык запросов так же убог как и в версии прошлого века. К счастию, вовремя разобрался с возможностями новой версии. И умею писать так чтобы работало быстро без захода в трассировщик теперь.
Понимаете в чем дело — бизнесу важно чтобы решались их задачи. За это они и платят. Гы, я «делец» по типажу из статьи наверное…
Что там внутри — начинает волновать только, когда все это тормозит или выдает результат, который не должно выдавать.
У меня — не тормозит. Не знаю почему. Наверно потому что я занимаюсь 1С профессионально уже 15 лет. Наверное потому, что и до 1С и параллельно с 1С я работал и с другими СУБД — Oracle, Tarantool, Cache.
ОК. Я верю что вы круче инженеров 1С.
Так как любые узкоспециализированные запросы будут эффективнее универсальных.
Не пользовался вашей разработкой на V8
Умею писать быстро на 1С V8 без прямых запросов.
На V77 пользовался подобной вещью. Сейчас это не нужно уже.
Однако, допускаю, что многим ваша разработка нужна и полезна.
Поэтому люди, которые изначально учились правильному SQL просто выпадают в осадок от результатов того, что им возвращает 1C
Наверное потому что они не понимают, что «правильный SQL» — это всего лишь база, основа для более сложных прикладных построений?
А 1С манипулирует с несколько иными структурами.
Скажем, запрос по регистрам работает не с одной таблицей, как это ожидал бы человек, знающий «правильный SQL», а с двумя таблицами сразу — таблицей итогов и таблицей движений. Которые на прикладном уровне видны как единое целое.
При этом вы наверно не знаете, что движок БД 1С используется без изменения со времен DBF файлов.
Я знаю это про версию 1C V77.
Там действительно SQL-версия 1С была реализована поверх движка DBF, что прилично подтормаживало.
Но эта версия была разработата еще в прошлом веке.
А с современной V8 — сильно сомнительно чтобы это было так.
По крайней мере скорость работы грамотно написанных запросов — чрезвычайно высока. Несопоставимо с V77
То есть такой способ расширения считается нормальным?
Требовать/ожидать от веб-сервера работать по стандартам?
Это везде является нормальным.
Описанная проблема нестандартного веб-сервера не имеет отношения к прикладным задачам для решения которых и создана платформа 1С.
Только что проверил. Мне удалось получить с веб-сервера сжатые данные. Там просто нужно самому заголовок «Accept-Encoding: желаемый метод сжатия» в http-клиенте 1С выставить.
Сдается мне, что этим ребятам из вашей ссылки интереснее решать не прикладную проблему в 1С, а чисто понабивать скиллы в .NET. Иначе зачем тратить так много времени? Допускаю, что они недостаточно компетентны в 1С. Но при этом компетентны в .NET. Что и предопределило способ решения задачи.
Ровно такая же ситуация с запросами в развитых CMS. Ровно такая же проблема будет с любой универсальной системой.
Вы протипопоставляете универсальное решения для работы с нетривиальными задачами — и узкоспециализированную систему.
Узкоспециализированная система всегда будет быстрее работать.
Но при этом научить узкоспециализированную систему делать что то дополнительное — будет оходится очень дорого.
Однако в случае т.н. «прямых запросов из 1С», ссылку на которые вы тут привели, позволю себе усомниться в целесообразности. В версии 1С V77 еще была иногда необходимость в прямом доступе к SQL, то в версии 1C V8 (которая появилась около 15!!! лет назад) — очень мощный язык запросов.
По вашей ссылке же я наблюдаю то, о чем я уже написал выше — вместо решения прикладных задач люди предпочитают тратить свое время на базовые ИТ-задачи.
Язык запросов в 1С очень гибок. Структура БД в 1С легко корректируется под задачу. И оптимизировать выполнение запроса можно вполне средствами 1С. Мне лично доводилось на ранних этапах написания запроса в 1С для какой-нибудь аналитики получать и по часу и по 2 часа выполнение запроса, которое после надлежащих оптимизаций превращалось в 30 секунд.
1С тут ничем не отличаются. Те кто пишут на SQL какую нибудь сложную аналитику в других системах — могут вам рассказать такие же истории.
По стандарту веб-сервер не должен посылать сжатый ответ, если клиент не выразил явным образом свое желание работать с сжатыми ответами.
Описано расширение платформы 1С штатными средствами. Эта технология существует уже лет 20. Используется в тех редких случаях, когда необходим какой-то доп. функционал и одновременно требуется жесткая интеграция модуля с платформой 1С. Например, для подключения какого-либо специального оборудования.
Я бы для обхода это косяка сервера (а не косяка клиента 1С) просто сделал бы http-прокси, а не стал бы делать внешнюю компоненту. но с начала — поигрался бы заголовками. А вдруг в каком то сочетании косячный веб-сервер начнет работать адекватно.
Вы привели в пример специфическую задачу, не имеющую никакого отношения к прикладной области для работы в которой и создана платформа 1С. Собственно, вы и подтвердили мою гипотезу, что я высказал выше. Программистов, в массе своей, напрягает решение непосредственно прикладной задачи, если она далека от ИТ. Им бы попрограммировать понятные базовые вещи — http, к примеру.
Васа 1628
Полтавская битва 1709
У меня есть шапочные знакомые, у которых бизнес на полмиллиарда.
Сайта у них нет, не было и не надо.
Имхо как раз хранимка — не то, ради чего стоит заморачиваться.
У меня вот есть СУБД на 1С интегрированная с отдельным веб-сервисом. Целый отдельный веб-сервис написать я еще понимаю смысл есть.
А хранимка — она забудется, потеряется, затрется при очередном обновлении 1С. То есть за ней нужно следить.
В 1C V8 подумывал про трассировщик — так как в начале освоения этой версии полагал, что язык запросов так же убог как и в версии прошлого века. К счастию, вовремя разобрался с возможностями новой версии. И умею писать так чтобы работало быстро без захода в трассировщик теперь.
Понимаете в чем дело — бизнесу важно чтобы решались их задачи. За это они и платят. Гы, я «делец» по типажу из статьи наверное…
Что там внутри — начинает волновать только, когда все это тормозит или выдает результат, который не должно выдавать.
У меня — не тормозит. Не знаю почему. Наверно потому что я занимаюсь 1С профессионально уже 15 лет. Наверное потому, что и до 1С и параллельно с 1С я работал и с другими СУБД — Oracle, Tarantool, Cache.
То есть идеалогия токенов предписывает делать идеальный веб-сайт без малейшей ошибки.
Я и говорю — вы энтузиаст.
Наш мир совсем другой.
Не технологии токенов (используемые фирмой совсем в другом месте, не на веб-сайте представительском/рекламном) определяют насколько доработан сайт.
Так как любые узкоспециализированные запросы будут эффективнее универсальных.
Не пользовался вашей разработкой на V8
Умею писать быстро на 1С V8 без прямых запросов.
На V77 пользовался подобной вещью. Сейчас это не нужно уже.
Однако, допускаю, что многим ваша разработка нужна и полезна.
С тех пор как ввели сервер в 1С — объектная модель стала хорошо работать с реляционными БД.
Объектная модель плохо ложится на реляционные БД, когда есть наследование. Без наследование — несовместимость минимальная.
О чем тогда говорить?
Любое ПО может и должно быть лучше — хоть 1С, хоть Android. А толку об этом мечтать если нет альтернатив (ну и ты сам эту альтернативу не пилишь).
Не показатель.
Я тоже, когда начинал в 1С, всё писал на английском. Язык позвволяет. Вы можете писать «если тогда», а можете писать «if then».
Потому перестал. Потому что идентификаторы прикладной области слишком нетривиальные, чтобы писать их на неродном языке.
При том на языке Go, к примеру, у меня английские идентификаторы используются.
Контекст вашего разговора по ссылке непонятен.
Задайте прямой полный вопрос здесь.
Наверное потому что они не понимают, что «правильный SQL» — это всего лишь база, основа для более сложных прикладных построений?
А 1С манипулирует с несколько иными структурами.
Скажем, запрос по регистрам работает не с одной таблицей, как это ожидал бы человек, знающий «правильный SQL», а с двумя таблицами сразу — таблицей итогов и таблицей движений. Которые на прикладном уровне видны как единое целое.
Я знаю это про версию 1C V77.
Там действительно SQL-версия 1С была реализована поверх движка DBF, что прилично подтормаживало.
А с современной V8 — сильно сомнительно чтобы это было так.
По крайней мере скорость работы грамотно написанных запросов — чрезвычайно высока. Несопоставимо с V77
Ну дык знать то инструменты — задача разработчика.
А не заказчика.
И задача разработчика — показать имеющиеся альтернативы заказчику.
Требовать/ожидать от веб-сервера работать по стандартам?
Это везде является нормальным.
Описанная проблема нестандартного веб-сервера не имеет отношения к прикладным задачам для решения которых и создана платформа 1С.
Только что проверил. Мне удалось получить с веб-сервера сжатые данные. Там просто нужно самому заголовок «Accept-Encoding: желаемый метод сжатия» в http-клиенте 1С выставить.
Сдается мне, что этим ребятам из вашей ссылки интереснее решать не прикладную проблему в 1С, а чисто понабивать скиллы в .NET. Иначе зачем тратить так много времени? Допускаю, что они недостаточно компетентны в 1С. Но при этом компетентны в .NET. Что и предопределило способ решения задачи.
Вы протипопоставляете универсальное решения для работы с нетривиальными задачами — и узкоспециализированную систему.
Узкоспециализированная система всегда будет быстрее работать.
Но при этом научить узкоспециализированную систему делать что то дополнительное — будет оходится очень дорого.
Однако в случае т.н. «прямых запросов из 1С», ссылку на которые вы тут привели, позволю себе усомниться в целесообразности. В версии 1С V77 еще была иногда необходимость в прямом доступе к SQL, то в версии 1C V8 (которая появилась около 15!!! лет назад) — очень мощный язык запросов.
По вашей ссылке же я наблюдаю то, о чем я уже написал выше — вместо решения прикладных задач люди предпочитают тратить свое время на базовые ИТ-задачи.
Язык запросов в 1С очень гибок. Структура БД в 1С легко корректируется под задачу. И оптимизировать выполнение запроса можно вполне средствами 1С. Мне лично доводилось на ранних этапах написания запроса в 1С для какой-нибудь аналитики получать и по часу и по 2 часа выполнение запроса, которое после надлежащих оптимизаций превращалось в 30 секунд.
1С тут ничем не отличаются. Те кто пишут на SQL какую нибудь сложную аналитику в других системах — могут вам рассказать такие же истории.
И вам прям по душе скребет, когда те, кто используют родственные технологии и организовано это у них не самым идеальным образом.
Но люди всегда люди.
И никакой блокчейн это никогда не изменит.
Всегда будут какие-то мелкие косячки в оформлении сайтов, не всегда будут вымыты окна в офисе и пр. и пр.
А не пытаться натянуть единственный инструмент на все возможные задачи.
Можно про «прикладная задача не налезает на базовые вещи» поподробнее? Пример. А то непонятно что вы именно имеете ввиду.
Или по вашему платить по VISA тоже могут только программисты?
Из общего с ИТ — тут только некий модный нынче гиковско-хипстерский подход, который к слову не всем ИТ-шникам и свойственен.
Я вообще не понимаю зачем это на Хабре.
На Гигтайм бы это.
Интенсивная реклама через веб? В 21 веке это нечто особенное? Вы серьезно?
Если я пользуюсь телефоном по работе — то автоматически моя работа имеет существенную связь с телеком-отраслью?