Ну надо тогда законодательно копи-паст в эксель запретить)
Я не спорю, если я делаю какую-то витрину, к которой буду возвращаться - тогда и запрос в БД, и PowerQuery. Я же тут говорю про случай, когда хочется ad-hoc, на коленке, что-то быстро подсчитать. И в этом случае (как я писал выше) Эксель обещает справиться быстро, но на практике со всех сторон вылезают ньюансы.
Я тут ещё подумал: что ж меня так триггерит каждый раз с этих «апологий эекселя»? И, кажется, я понял: это обманутые ожидания.
Эксель говорит «дружище, давай к нам, я помогу перемолоть эту кучу данных всего парой кликов!» И ты радостно обращаешься к нему, ожидая, что через минуту у тебя уже будет готовый результат. Но через минуту ты ударяешься мизинцем об одну дырявую транзакцию: даты – не то, чем кажутся. Ничего, результат уже на горизонте – но вот новая проблема: у твоей любимой функции из обычных языков программирования не нашлось нужного аналога. Ничего, и это можно перебороть – пишем 3-этажную формулу, вытираем пот со лба – опять что-то работает не так, как ожидал.
Да, понятно, надо знать ограничения инструмента (=уметь им пользоваться). Но у меня глубокое впечатление, что эксель обещает сильно больше, чем потом может исполнить. Оттого и такая обида на этот инструмент.
Мне хватило раз по 20 наступить на пару моих любимых граблей с экселем:
Берём вывод из MS SQL Management Studio, где есть даты и копи-пастим в эксель. Чу! Часть строчек выпадает из статистики потому что Студия добавила миллисекунды через точку и Эксель посчитал, что это теперь не дата, а строка. Не беда! Поменяем формат ячейки на строку... Ой - теперь у меня вместо дат какие-то красивые цифры, 4-с-чем-то-тысячи. Надо было сразу в Jupyter сделать pandas.read_clipboard() и не было бы проблем.
Возьмём логи и попробуем вытащить подстроку из сообщений. Ой, НАЙТИ() в случае ненахождения подстроки выдаёт исключение! Не беда, обернём его в местный try-catch и тогда, после пары таких комбинаций, в нашей формуле уже никто и никогда не разберётся. Надо было тоже сразу делать pandas.read_clipboard(), а потом уже можно было str.extract с поиском по регуляркам...
Да, можно всё это делать в VBA, но можно же с тем же успехом использовать и Python? Последний в этом сравнении мне нравится больше, а тут как ни крути, начинается уже вкусовщина.
Эксель до сих пор использую для быстрой фильтрации по заголовку таблицы. Или для рисования графиков. Но какие-то преобразования данных уже давно делаю в питоне - там я получу результат за предсказуемое время, не попадая на неожиданности вроде формата дат или непривычной работы find/charindex/и т.п.
Тут речь все-таки про MS SQL Server. Он и для кластерных «листьев», и для страниц кучи хранит контрольную сумму (ну или первые биты для torn page detection, как настроить).
Так что у Heap могут быть проблемы со скоростью чтения, но в плане надёжности она не проигрывает кластерным индексам
Если сократить вашу мысль получается «государство [Аргентины] не умеет управляться с деньгами — давайте деньгами будет управлять Святой Блокчейн!» В целом, справедливо, только вместо блокчейна можно подставить любое другое слово и — сюрприз! — ничего не изменится. Вот в в Зимбабве действительно взяли и отобрали управление деньгами у своего государства — и переложили эту обязанность на другое государство, которое, по их мнению, управляется лучше. И остались довольны.
В этой области блокчейн не единственное решение. И не самое эффективное (транзакции выполняются чудовищно долго). Так что это далеко не святой Грааль
Хорошая статья, не знал, что для Plan Guide есть свои хранимки.
Я бы ещё добавил, что если уж очень хочется помахать молотком с гвоздями — в SQL Server 2016 появился Query Store, который позволяет явно назначить запросу один из недавних планов (предполагается, что среди нескольких последних планов был один, самый эффективный). Ссылка на BOL и best practice
Ок, неправильно выразился. Не нашёл какого-то мейнстрим-решения, которым принято пользоваться. Хочется же не просто что-то сделать на коленке, но и получить актуальный опыт, который может еще пригодиться.
Собственно, изначально в голове была такая идея: сделать каким-нибудь инструментом вёрстку, а потом нагрузить ее каким-нибудь модным JS-фреймворком. Ну и когда выяснилось, что с первым пунктом не получается, перестроился на React.
В меня сейчас начнут кидаться помидорами, но я напишу 2 страшных символа: 1С
Начиная с 8.2 там появились управляемые формы, где невозможно просто взять «кинуть кнопку на форму», надо обязательно указать ей, в каком блоке она будет, как этот блок будет себя вести при растягивании/сжимании и т.п В итоге получается вёрстка, похожая на последнюю картинку в посте: всё поделено на функциональные блоки и подстраивается под экран. Причём всё это делается (прости, Господи) мышкой, без программирования стилей.
Форма выглядит как дерево объектов с заданным поведением.
Я на карантине собрался сделать простенькую игрушку с фронтом на JS, попытался найти похожий визуальный редактор и с удивлением обнаружил, что ничего подобного просто нет. Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css
Когда слышу истории про «я программист и не вижу результата своего труда» всегда вспоминаю эту историю:
«вообще, только в этом проекте понял я всю страшную мощщ хайтека. ощущаешь себя просто доктором Франкенштейном, выпустившим на волю монстра. щелк, щелк мышкой — бабах! все трясецца, турбина запускаетца, цифирки бегут по экрану! щелк, щелк! все смолкает. ууух.»
Каждый раз я как-то умудряюсь найти эту турбину. Пусть она где-то за тысячу километров, пусть я туда добавил только какой-то комментарий — но она крутится в том числе из-за меня. Люди принмают звонки, вносят документы в ERP, бизнес движется — потому что я помог это организовать. Вот оно, маслоувское чувство пречастности к чему-то большому, досталось мне практически сразу. Так и работаю :)
Посмотрел на «испорченное» видео и вспомнил — а ведь на самой заре коммерческого телевидения такую штуку пытались внедрить в Воронеже!
Местная телестанция вещала на двух (дециметровых, если правильно помню) каналах. Большая часть эфира была открытой, но вечером, когда выпускали свежие боевики, канал «кодировали». Для расшифровки нужно было купить специальный «декодер» и платить абонентку.
Декодера у меня никогда не было, но я помню, как пытались с друзьями починить сигнал, подкручивая регулятор частоты в «Рекорде» )
Жило это недолго, 93-94 год примерно. Точно не вспомню уже.
К сожалению, сейчас возможности проверить уже нет. Но, теоретически, действительно могло бы помочь — если только операция не вылетит с ошибкой.
Я не стал делать ребилд сразу, т.к. надо было понять, что именно случилось с индексом. Ну а когда картина прояснилась, выбрал вариант с ручной перезаливкой, как более «надежный»: на каждом этапе тут указываются команды, которые не допускают вольностей с выбором плана выполнения. Ну то есть, процесс получается более контролируемым.
Тут просто надо подумать, как будет оформляться этот «уставной капитал». Никто же не говорит просто «вот, держите, моя доля в УК». Эта доля чем-то обеспечена.
Принес деньги — положили их в банк на 51 — в корреспонденции остался УК как «обязательство» перед учредителем за эти деньги
Принес компьютер — положили его в Основные средства (на самом деле нет). В корреспонденции опять УК, который явно оказывается пассивом.
В общем, надо к проводке все сводить, тогда становится понятнее
Не знаю, как в МСФО, но по РСБУ довольно простое разделение: активы — это то, что можно «потрогать руками», пассивы — это обязательство (очень упрощенно: долги)
Например, пришел товар от поставщика: одновременно увеличился активный 41 счет (пришло что-то материальное) и так же увеличился 62 счет — мы стали «должны» поставщику денег за товар. Заплатим деньги с «материального» 51 счета и наш «долг» закроется.
Когда только начинаешь изучать бух. учет бывает очень полезно спрашивать себя «можно ли это потрогать?». Если можно — счет точно активный, ставим его в Дт или Кт в зависимости от того, плюс это или минус. Ну а корр. счету остается незанятое место в проводке
1. В статье не использовались механизмы, для которых нужна нормализация. Простой поиск по подстроке, без синонимов и прочего. Для создания индексов использовался Английский язык, кроме последнего примера, с внешним word breaker
2. Тут, к сожалению, простого способа нет. Ну или я его не нашел. Можно следить за очередью по конкретной таблице при помощи команды
SELECT OBJECTPROPERTY(object_id('partners'), 'TableFulltextPendingChanges')
Ну и, соответственно, ждать полного «рассасывания» очереди или просто следить за дельтой.
В MS SQL достаточно «открутить» значение max degree of parallelism до 2-4 и выше и тогда запросы так же будут параллелиться на 2-4 или больше потоков. 1С перестраховывается и не рекомендует этого делать (оно и понятно: в кривых руках можно одним запросом съесть все ядра).
Вы дальше пишете, что «стоит отдельно <..> включить [параллелизм] для MS SQL», но меня резанула фраза, что «этого не получается для MS SQL». Фактически же, и там, и там это дополнительные настройки, так что тут все в равных условиях.
В MS SQL давно (то ли с 2005, то ли с 2008) появилась возможность работать как с «версионником» (read committed snapshot isolation). Операции чтения в режиме Read Committed теперь не ждут завершения изменяющей транзакции, а читают версию на момент «до начала изменения»
1С работает в этом режиме начиная с 8.3.1. Так что по блокировкам большой разницы быть не должно
Ну надо тогда законодательно копи-паст в эксель запретить)
Я не спорю, если я делаю какую-то витрину, к которой буду возвращаться - тогда и запрос в БД, и PowerQuery. Я же тут говорю про случай, когда хочется ad-hoc, на коленке, что-то быстро подсчитать. И в этом случае (как я писал выше) Эксель обещает справиться быстро, но на практике со всех сторон вылезают ньюансы.
Ну вот Pandas же как-то научился с ней справляться. Ни разу с ним таких проблем не было
Я тут ещё подумал: что ж меня так триггерит каждый раз с этих «апологий эекселя»? И, кажется, я понял: это обманутые ожидания.
Эксель говорит «дружище, давай к нам, я помогу перемолоть эту кучу данных всего парой кликов!» И ты радостно обращаешься к нему, ожидая, что через минуту у тебя уже будет готовый результат. Но через минуту ты ударяешься мизинцем об одну дырявую транзакцию: даты – не то, чем кажутся. Ничего, результат уже на горизонте – но вот новая проблема: у твоей любимой функции из обычных языков программирования не нашлось нужного аналога. Ничего, и это можно перебороть – пишем 3-этажную формулу, вытираем пот со лба – опять что-то работает не так, как ожидал.
Да, понятно, надо знать ограничения инструмента (=уметь им пользоваться). Но у меня глубокое впечатление, что эксель обещает сильно больше, чем потом может исполнить. Оттого и такая обида на этот инструмент.
Мне хватило раз по 20 наступить на пару моих любимых граблей с экселем:
Берём вывод из MS SQL Management Studio, где есть даты и копи-пастим в эксель. Чу! Часть строчек выпадает из статистики потому что Студия добавила миллисекунды через точку и Эксель посчитал, что это теперь не дата, а строка. Не беда! Поменяем формат ячейки на строку... Ой - теперь у меня вместо дат какие-то красивые цифры, 4-с-чем-то-тысячи. Надо было сразу в Jupyter сделать pandas.read_clipboard() и не было бы проблем.
Возьмём логи и попробуем вытащить подстроку из сообщений. Ой, НАЙТИ() в случае ненахождения подстроки выдаёт исключение! Не беда, обернём его в местный try-catch и тогда, после пары таких комбинаций, в нашей формуле уже никто и никогда не разберётся. Надо было тоже сразу делать pandas.read_clipboard(), а потом уже можно было str.extract с поиском по регуляркам...
Да, можно всё это делать в VBA, но можно же с тем же успехом использовать и Python? Последний в этом сравнении мне нравится больше, а тут как ни крути, начинается уже вкусовщина.
Эксель до сих пор использую для быстрой фильтрации по заголовку таблицы. Или для рисования графиков. Но какие-то преобразования данных уже давно делаю в питоне - там я получу результат за предсказуемое время, не попадая на неожиданности вроде формата дат или непривычной работы find/charindex/и т.п.
У Гарри Гаррисона ещё была повесть в стимпанковской альтернативной вселенной про Трансатлантический Туннель - как раз по описанию Hyperloop
Так что у Heap могут быть проблемы со скоростью чтения, но в плане надёжности она не проигрывает кластерным индексам
В этой области блокчейн не единственное решение. И не самое эффективное (транзакции выполняются чудовищно долго). Так что это далеко не святой Грааль
Я бы ещё добавил, что если уж очень хочется помахать молотком с гвоздями — в SQL Server 2016 появился Query Store, который позволяет явно назначить запросу один из недавних планов (предполагается, что среди нескольких последних планов был один, самый эффективный). Ссылка на BOL и best practice
Собственно, изначально в голове была такая идея: сделать каким-нибудь инструментом вёрстку, а потом нагрузить ее каким-нибудь модным JS-фреймворком. Ну и когда выяснилось, что с первым пунктом не получается, перестроился на React.
Начиная с 8.2 там появились управляемые формы, где невозможно просто взять «кинуть кнопку на форму», надо обязательно указать ей, в каком блоке она будет, как этот блок будет себя вести при растягивании/сжимании и т.п В итоге получается вёрстка, похожая на последнюю картинку в посте: всё поделено на функциональные блоки и подстраивается под экран. Причём всё это делается (прости, Господи) мышкой, без программирования стилей.
Форма выглядит как дерево объектов с заданным поведением.
Я на карантине собрался сделать простенькую игрушку с фронтом на JS, попытался найти похожий визуальный редактор и с удивлением обнаружил, что ничего подобного просто нет. Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css
«вообще, только в этом проекте понял я всю страшную мощщ хайтека. ощущаешь себя просто доктором Франкенштейном, выпустившим на волю монстра. щелк, щелк мышкой — бабах! все трясецца, турбина запускаетца, цифирки бегут по экрану! щелк, щелк! все смолкает. ууух.»
Каждый раз я как-то умудряюсь найти эту турбину. Пусть она где-то за тысячу километров, пусть я туда добавил только какой-то комментарий — но она крутится в том числе из-за меня. Люди принмают звонки, вносят документы в ERP, бизнес движется — потому что я помог это организовать. Вот оно, маслоувское чувство пречастности к чему-то большому, досталось мне практически сразу. Так и работаю :)
Местная телестанция вещала на двух (дециметровых, если правильно помню) каналах. Большая часть эфира была открытой, но вечером, когда выпускали свежие боевики, канал «кодировали». Для расшифровки нужно было купить специальный «декодер» и платить абонентку.
Декодера у меня никогда не было, но я помню, как пытались с друзьями починить сигнал, подкручивая регулятор частоты в «Рекорде» )
Жило это недолго, 93-94 год примерно. Точно не вспомню уже.
Я не стал делать ребилд сразу, т.к. надо было понять, что именно случилось с индексом. Ну а когда картина прояснилась, выбрал вариант с ручной перезаливкой, как более «надежный»: на каждом этапе тут указываются команды, которые не допускают вольностей с выбором плана выполнения. Ну то есть, процесс получается более контролируемым.
В общем, надо к проводке все сводить, тогда становится понятнее
Например, пришел товар от поставщика: одновременно увеличился активный 41 счет (пришло что-то материальное) и так же увеличился 62 счет — мы стали «должны» поставщику денег за товар. Заплатим деньги с «материального» 51 счета и наш «долг» закроется.
Когда только начинаешь изучать бух. учет бывает очень полезно спрашивать себя «можно ли это потрогать?». Если можно — счет точно активный, ставим его в Дт или Кт в зависимости от того, плюс это или минус. Ну а корр. счету остается незанятое место в проводке
2. Тут, к сожалению, простого способа нет. Ну или я его не нашел. Можно следить за очередью по конкретной таблице при помощи команды
SELECT OBJECTPROPERTY(object_id('partners'), 'TableFulltextPendingChanges')
Ну и, соответственно, ждать полного «рассасывания» очереди или просто следить за дельтой.
Забавно) Спасибо, запомню
Вы дальше пишете, что «стоит отдельно <..> включить [параллелизм] для MS SQL», но меня резанула фраза, что «этого не получается для MS SQL». Фактически же, и там, и там это дополнительные настройки, так что тут все в равных условиях.
1С работает в этом режиме начиная с 8.3.1. Так что по блокировкам большой разницы быть не должно