Comments 247
Если уж по альтернативам Airtable проходиться - то nocodb, Seatable и Baserow странно не упомянуть, да и вообще сотни их. Но вот это всё реально скорее Access, чем Excel. Во-первых, обычный офисный работник с гораздо меньшей степенью вероятности осилит соорудить какой-то инструмент "наколенной автоматизации" с помощью этих инструментов - а в этом вся сила Excel. Во-вторых, по функционалу есть принципиальные расхождения.
размер таблицы достигал 77 000 строк.
И они наверняка не единственные компании, которые пытаются втиснуть большие данные
77к строк и это большие данные. Большие данные, Карл !!!!! BigData, епт. Кластер датабрикса надо развернуть в Azure чтобы там сводную таблицу пересчитать :)
Учитывая что работа с данными ведется напрямую в самой даблице - это вполне себе BigData в мире Excel.
Даже в мире эксель это копейки, он даже не шелохнется на таком объеме.
Обновления для слабаков
Помнится, когда-то в ворде было "быстрое сохранение". И можно было нарваться, что отправил документ кому-то, а он мог увидеть удаленные куски, поскольку при быстром сохранении только изменения дописывались. И нужно было Save As делать, чтобы почистить. Заодно и размер файла уменьшался.
Как сейчас с этим?
2007 excel в 2024 году? А что не 97?
Я бы систему счисления заменил на какую-нибудь другую, а то что-то давно не обновляли. 10-чная надоела, хочу 30-ричную!
Ну, если новая система счисления будет значительно удобнее десятичной, то почему нет?
Римские же цифры арабскими заменили :)
У меня были аргументы за 30-ричную. Там мировые физические константы можно выразить круглыми числами. Но, я думаю, сейчас уже не найдётся аргументов такой силы, чтобы заменить 10-чную на что-то ещё.
У американцев, говорят, находятся... /s
Ну вообще у них система вполне себе десятичная. Единицы измерения, да, не метрические. Но это аргументы за сохранение старой системы, а не за переход на новую, это немного разные вещи.
Вполне себе десятичная
Ну да, ну да, 16 унций в фунте, 12 дюймов в футе, 4 кворты в галлоне, 4 чашки в кворте, 8 унций в чашке... В общем, аккуратнее, не сломайте тут себе чего-нибудь..
16 унций в фунте, 12 дюймов в футе, 4 кворты в галлоне, 4 чашки в кворте, 8 унций в чашке
Это всё - десятичная система счисления.
Система счисления не имеет отношения к количеству одного в другом, она влияет на то, как это кол-во будет записано (выражено в письменном виде).
F0 унций в фунте, 0C дюймов в футе - вот это уже не десятичная.
Это всё - десятичная система счисления.
Тогда каким боком тут американцы? Десятичная система счисления — она сейчас более-мнее у всех на этой клёпаной планете (ну, кто не живёт в хижинах).
Не пойму, вроде тег в наличии, а форточку всё равно открывать нужно...
Не вполне десятичная. Дюймы делятся по степеням двойки. Как минимум, в строительстве
То есть, 3/4 дюйма они записывают как 0.11?
Нет, разумеется. Но и не 0.75.
В моем понимании, запись числа дробью - это не десятичная система.
Собственно говоря, мы читаем числа тоже не в десятичной, а в "сложно позиционной" системе (сотни, тысячи, миллионы)
Но и не 0.75
А как именно? 3/4 это тоже десятичная система, если что. Я понимаю, что иногда числа можно записать не десятичной системой. Просто в целом США пользуются десятичной. Система счисления и единицы измерения это не одно и то же. Отношения между единицами измерения могут не быть степенью 10, но эти отношения (какие бы они ни были) вы записываете в десятичной позиционной системе или дробями, где числитель и знаменатель оба десятичные числа.
Наверное, не хватило 65000 строк
Если вы переедете на Excel 2021 или 2024, замените устаревший ВПР на ПРОСМОТРX, уберете обычные массивы (тут сложно в лоб детали посоветовать без анализа файла), пересохраните файл в xlsx — уже всё это наверняка уберёт тормоза.
Ну и памяти на компе, надеюсь, не 4 гига?)
замените устаревший ВПР на ПРОСМОТРX
И давно ВПР дает тормоза?
И всю жизнь был и есть ИНДЕКС(), который все эти впры и просмотрхы рвет как тузик грелку.
У меня новый Excel может иногда внезапно подвисать на некоторых файлах при копировании данных через буфер. Так и не разобрался почему.
копирование информации из ячейки в ячейку методом перетаскивания работает неправильно: только по строкам или только по столбцам, или вообще никак (хотя я перетаскиваю ячейку),
Перетаскивание ячейки должно приводить к перемещению, а не копированию. Либо я неправильно понимаю Ваш текст.
или наоборот вдруг копиями заполняется весь столбец до конца таблицы (хотя я такой команды не давал);
Проверьте дабл клик на ЛКМ. Потому что это именно такая команда: дабл клик ЛКМ на правом нижнем углу ячейки приводит к протягиванию ячейки до конца таблицы.
часть ячеек (в том числе служебных - с номерами строк или заголовками столбцов) - вдруг покрывается чёрными прямоугольниками, причём графических артефактов в других программах я не наблюдаю, только в Excel;
Excelю возможно не хватает оперативки.
при отключении фильтров, фильтрация иногда не снимается - таблица перестаёт прокручиваться выше n-ной строки;
Закрепление ячеек/строк точно не стоит?
при работе с фильтрами, если удалить информацию в столбце - она удалится из отфильтрованных ячеек, и из всех что между ними;
Это стандартное поведение 2007 и более древних версий экселя. Пользуйтесь функцией выделения только видимых ячеек или перейдите на более свежую версию.
пару раз случались "вылеты".
Только пару? )
Как можно держать там таблицу на 77к строк - не представляю. Это ужас.
Таблица с 2011 с почасовками. 116к строк, 0,5к столбцов. Только данные (без формул) - работает как часы. И да, с лета 2011 года прошло 116к часов :)
Крутил в экселе несколько таблиц с формулами по ~300тыс записей и ничего не тормозило. Главный минус экселя - если падает одна книга, то падают все.
По моему опыту эксель это лучший инструмент для быстрого и наглядного EDA
Это пока с таблицей работать. А любая попытка построить по этой таблице график - привет, тормоза.
Можно сделать сводную, агрегацию, экстраполяцию. Не представляю кейса, когда нужен график на 77000 поинтов, а не просто на 77.
Допустим, 77000 магазинов в сети, расположенных в 770 населенных пунктах в 77 регионах, которые агрегированны в управленческой структуре сети в 7 дивизионов. И вот есть управленец (заказчик отчётности), который хочет иметь инструмент 2в1 - подзорную трубу и микроскоп, чтобы с самого верхнего уровня можно было "проваливаться" до самого нижнего. А на самом нижнем он хочет видеть 77000 точек на графике, которые, ожидается что будут иметь форму какого-то структурированного облака. И в этом облаке заказчик хочет найти для себя какой-то инсайт (его может и не случиться, но заказчик всегда прав).
Ок, пример вполне реальный, и от жизни не оторван. Тогда есть 3 варианта:
Костыль. Все равно сделать агрегацию данных (сводную или доп. колонку), и строить верхнеуровневый график на этих данных. Во всяком случае, при обновлении источника или при переоткрытии файла тормоза уйдут. Но делать drilldown будет неудобно, или придётся развивать костыли и на другие уровни.
При создании сводной засунуть данные в "модель данных" (Power Pivot), и далее все операции делать уже на ней. Даже не обязательно сразу в формулы и язык DAX сразу лезть изучать — делаете обычную сводную таблицу/диаграмму, как раньше. Если исходников много, или они разные, или много "мусора" и ненужных данных — нормализуйте и причешите исходники через Power Query
Переходить на полноценные BI системы. Можно начать с Power BI, он тоже от Microsoft, эдакий Excel на стероидах, и бесплатный для единичного применения "для себя" -- не будет опции публикации и расшаривания готовых дашбордов на весь мир, будет сразу нативная интеграция в тот же PowerPoint для презентаций. Или альтернатива: Tableau, DataLens, Apache Superset, Visiology и тд, их много разных, в том числе и опенсорсные.
Не забыть добавить срезы во все эти 1-2-3, чтобы было, на чём делать этот самый drilldown. Нередко уже на первых шагах становится очевидно, какие конкретно срезы/параметры в исходнике вносят наибольший вес в аномалии на графике или образуют интересные зависимости между собой.
Путь в 2 и 3 рекомендую начать отсюда: https://www.planetaexcel.ru/techniques/24/5854/
Благодарю за рекомендацию, я просто привела пример. У нас уже все это энергично используется, и этого тоже уже не хватает. И power bi есть. Но все равно все данные кусками, из которых по случаю пересобирается новый отчёт. И я не представляю, какой софт и какое железо может переварить объем данных, к примеру, по продажам 10000магазинов*10000наименований*365дней*3года, чтобы все это влезло в 1 отчёт и благополучно там ворочалось с уровня дивизион-год до уровня день-магазин. У нас есть достаточно сложные модели, но и они разбиты по способам агрегации и фильтрации. Поэтому наш заказчик сидит без облачка из 100млн разноцветных точек в динамике за 3 года по дням.
planetaexcel - вещь!!!
Я работаю с данными, которые пишет силовая машина. Образец растягивается или сжимается, и сохраняются данные в виде таблицы "Сила - Перемещение". Потом я эти данные закидываю в Excel, чтобы сделать по ним некоторый анализ - например, определить, где началась площадка текучести, какая максимальная сила была достигнута перед разрушением или какое перемещение было между силой 500 Н и 1000 Н. Чем больше у меня точек - тем точнее результат. И одновременно мне хочется видеть эти данные в виде графика в тех же координатах "Сила - Перемещение" с возможностью этот график приблизить в нужной точке. Вот и приходится строить его по всему массиву без агрегации.
Да, можно взять MathCAD, и если мне надо сделать сложный анализ - например, посчитать площадь под кривой (т.е. энергию, запасенную например в сжатой пружине) - я беру именно его. Но простые задачи быстрее сделать в Excel.
Выше дал развёрнутый комментарий, как строить диаграммы на больших массивах исходных данных, загляните, может и вам подойдет.
Если там так много точек, может лучше просто написать свой скрипт для обработки. После того как взяли производную или интеграл от массива точек (очень предсказуемая процедура), конечный результат обработки не должен содержать так много данных. Вот его и нужно отдавать Excel
Смотря сколько столбцов, у нас есть файлик 25000 строк 550 столбцов. Несколько вкладок с расчетами и куча формул:) даже на мощных серверах с ссд он открывается минут 10:) сохраняется минут 5:)
Вполне возможно, Excel не совсем подходящее средство для вашего случая. Возможен вариант, что спроектировано не оптимально. У меня были большие файлы, я отключал пересчёт ячеек, пересчитывал файл по команде, когда была необходимость. Соответственно, сохранять такой файл тоже нужно с отключённым расчётом формул, чтобы при открытии он не запускал сразу же перерасчёт.
Надо было как то раз провести несколько манипуляций в таблице на 55к строк и 5 столбцов. По итогу пришлось переводить ее в dataframe pandas и дальше уже так с ней возиться. Так что насчет того, что 70+к строк ексель прожует без проблем я не согласен, особенно в мире офисного железа.
если Excel использовать с умом, то тормозить он начинает только при приближении к 1 млн. строк, а если руки кривые - можно его сломать парой сотен)
а с PowerPivot'ом лично я крутил файлы по 20 млн строк - и всё было ок
BigData это не про количество, а по объем работ, который привычным способом невозможно решить за разумный срок или разумные ресурсы
P. s. Проблема не в Экселе, а в том, что компании сэкономили на нормальном программисте или команде, которая бы поддерживала бизнеспроцессы компании, используя адекватные инструменты и языки программирования, с помощью которых полученный результат можно было бы поддерживать.
Т.е. компании страдают от классического технического долга.
Я в бигдату не верю. В интернет-магазинах мне постоянно рекламируют товар, который я уже купил у них же полгода назад, в качестве комплектующих к покупке предлагают какие-то рандомные вещи, вместо реальных комплектующих к этому самому товару, и такое сплошь и рядом. По мне дак это термин, оправдывающий бесконечный сбор и "поддержание" (бэкап бэкапа бэкапа) того объема информации, что есть у организаций, и который, по сути, является аналогом полезного хлама в кладовке, который жалко выкинуть потому что "а вдруг пригодится".
Просто у рекламодателей не настроена сквозная аналитика в разрезе "реклама-реальная продажа". А она (сквозная аналитика + юнит-экономика) рулит, как раз расскажет бизнесу куда и в каких пропорциях надо перераспределять рекламный бюджет и какой товар низкомаржинальный из-за высокой себестоимости.
Очень мало интернет-магазинов отслеживают всю цепочку с обоих сторон (полная себестоимость товара и рекламы в разрезе реальной совершённой продажи)
Здесь я не специалист, сужу только по тому, насколько удобны магазины мне как покупателю. Факт такой: в любом интернет-магазине никогда не было такого, что купил товар из предложки (тот элемент интерфейса, где перечислены вещи в духе "возможно, вам понравятся"). Как я понимаю, это и есть одна из родных задач биг-дата: проанализировать всю историю покупок человека, а также все его действия на сайте (что открывал, что смотрел внимательно, а что просто пролистал, что добавил в избранное, а потом убрал и т.д.) и предложить что-то, что он реально купит. И это по каким-то причинам не работает.
Когда товаров 100 000+ — сложно предложить что-то релевантное, даже при 100% наличии релевантного. Например, при покупке дрели предложить сверла. Какие? По дереву, бетону, металлу? Да их там в каждой категории ещё тысячи будут. В лучшем случае зайдёт набор свёрел ("start kit"). И выстраивание хорошей рекомендательной цепочки "с этим товаром покупают это" или "вы купили дрель, вот вам болгарка или перфоратор" — не тривиальная задача.
Для небольшой товарной матрицы (число разных артикулов) можно и полный рандом сделать. Условно, 1% зайдёт по ссылке и докупит. А когда матрица огромная — 100 000 sku, и аналитика для рекомендаций будет кратно сложнее, и не всегда есть смысл в детализации: достаточно предложить хотя бы категории сопутки или "посмотрите ещё это"
в том, что компании сэкономили на нормальном программисте или команде
Как же у вас все просто... Вот, нанять команду, и сразу бардак исчезнет. Проблема в том, что, как раз, наоборот, программист или команда у тех, кто до этого не дорос, вызывают куда более сильные и принципиальные проблемы, чем Эксель. Эксель дал невиданную децентрализированность, версионность и lock-free архитектуру каждому. Любой линейный менеджер с головой может решить дохрена своих проблем с ним, вообще не отвлекая никого, не доказывая никому важность, и не ущемляя ничьих интересов. Видел примеры, когда компании переходили на "серьёзный" подход после Экселя, и гибкость и скорость падали драматически. Там, где ранее перестраивались за 2 часа, теперь надо описать и поставить задачу, убедить продакт овнера в важности, дождаться релиза, протестировать, объяснить, что вышло не то, дождаться фикса... Это даже не дни, а месяцы, увы
Поднятия правильные вопросы. Но вывод скорее не верны. В ошибках человека обвинили программу! Понятно, что программа имеет ограничения. Открою одну истину автору, все без исключения программы имеют ограничения. Просто они разные и человек-оператор ОБЯЗАН!!! знать их уметь с ними "жить". Подобный поклёв на Excel и смена его на другой софт приведёт только к тому, что через некоторое время аналогичный поклёв начнётся и на новый софт.
Под каждую задачу нужный свой инструмент. Без сомнения, если параметры задачи входят за рамки программы, она должна быть заменена. Но и человек должен обладать компетенциями, и так же должен быть заменён другим человеком, если ими не обладает.
Руководство проектов не обеспечило подготовку/переподготовку персонала, персонал забил на технические нормы, как следствие возникли сбои - а виновата программа. Вывод супер!
В принципе да. Каждый инструмент для своей целей. Тем более, под Экселем можно понимать сразу несколько офисных табличных процессоров. И большой плюс в их совместимости и относительной универсальности.
поклёП
Не совсем так. Это лень человека, помноженная на незнание.
Следите за руками
1) Юзер пишет в MS тикет об "ошибке": "Я написал в ячейку FEB3 (имея в виду 3 февраля), а теперь хочу прибавить к этой дате 10 дней а оно не работает!!!АДЫНАДЫН!"
2) Программисты пожимают плечами — "мужик, ну ты чё, тупой? надо объявить ячейку как тип "дата" и писать в ней не FEB3, а FEB-3"
3) Юзер начинает орать "ах вы так не хочу ничего объявлять хочу чтобы оно само работало!!! больше не буду покупать этот ваш йоксель!!!111". НабИгают манагеры.
4) Манагеры отпаивают юзера валерьянкой 40-летним виски, другой рукой вставляя программистам пистон третьего размера. Те переписывают код так, чтобы любые данные, которые ну хоть как-то похожи на дату, вызывали автоматическое изменение типа ячейки на "дата".
5) В MS поступает тикет об уже реальной ошибке — "я вставляю в ячейку текст с названием гена MARCH1, а он почему-то переделывается в дату MAR-1!!!" (а это сработала эвристика из пункта 4, ведь MARCH1 и правда похоже на дату).
6) Из рощи фейспальм выглядывают программисты и напоминают, что они в домике — они просто разместили объяву закрыли тикет, при этом предъявляя в доказательство пистон третьего размера из пункта 4. Попытка найти манагеров не удаётся — они уже давно покинули судно с золотыми парашютами.
Вот так и живём...
А что по поводу Originlab? В научной работе он уже у большинства заменил эксель, по моим наблюдениям (скрин в аттаче).
Он гораздо быстрее поддерживает большие объёмы данных (субъективно), плюс вот эти все фишечки по настройке графиков или даже фиту спектральных данных присутствуют.
Ну и в ячейках у него можно писать скриптами на питоне =)
Верно. С вероятностью 99.9% можно утверждать, что если в статье графики из Excel - статья гамно
Только если в стандартных стилях по-умолчанию)))
Главное удобство Ориджина это не вся эта бигдата (что конечно не плохо), а то, что можно просто скопировать стиль оформления рисунка и применить ко всем остальным. В Экселе это нужно делать вручную, ибо стили там не редактируемые, а это больно, если много рисунков. Хотя считать в нем удобнее. По этому на практике, часто считают в Экселе, а строят в Ориджине. Ну и ценник, да, Эксель по факту бесплатный и есть везде, а Ориджин это штука по цене сопоставимая с профессиональными средствами разработки типа автокада или фотошопа.
Ну да. Только когда люди начинают в нем ещё и расчеты вести, и потоковые данные обрабатывать -- столько же замечательных скриптов и плагинов есть ! -- образуется замечательный Excel номер 2, только влияние, к счастью, сильно более ограниченное.
Потому что origin - это программа отображения табличных данных в форме графиков.
Только теперь оно еще и data analysis, и методы для BigData разумеется там тоже завезли.
Использую origin для всяких расчётов и обработок потоков данных, когда их не так много и заводить полноценный python или какой-нибудь igorpro будет дольше. А таких ситуаций много, на самом деле, в научной работе - обработать как-то по быстрому 50 спектров определённым образом (с учётом, что не нужно это будет повторять в течение хотя бы полугода). 50-100 столбцов данных это как раз тот размер для меня, что полноценную программу или скрипт писать и отлаживать дольше, чем в ориджине потыкать.
Ну и к тому же, не все учёные программируют, для них условные скриптики, которые сейчас в ориджине почти для всего - это спасение.
Цены просто конские.
Для нон-профит и всяких индивидуалов 925$ за лицензию.
Что-то ужасное из 90х, судя по скрину)
А, если серьёзно, то странно видеть, что в научной среде люди используют это, имея связку jupyter notebook + python, ну, или, вообще R, если олдскул
В науке оно все распределилось
R - не олдскул, а примерно 80% всей современной биоинформатики и заметный кусок биостатистики
jupyter + python это всякая другая биология и имадж-процессинг
ОриджинЛаб - в основном у физиков и химиков, которые не всегда умеют программировать
Это физики то не умеют программировать?
Удивительно, но да. Особенно старшее поколение, хотя конечно есть всякие.
Ну и от направления зависит, я плотно только с материал сайентистами общаюсь
Драйвера на звук вряд-ли, а вот рунгекут в рунгекуте старшее поколение на фортране писало легко. Что уж там говорить о визуализации данных - это побочная работа любого физика.
В наших вузах с программированием очень и очень плохо, особенно у физиков/химиков. Обычно это проходной курс в общей специальности, где будет какой нибудь матлаб, паро довольно сложных заданий, которые студенты решат с помощью gpt либо срисуют где-то. В зарубежных уже чуть лучше, там пробиваются Юпитеры и тп, но замечаю что где-то с прошлого года пошли в огромной количестве кривые решения на gpt + какие-то костыли дописанные руками.
Так у меня есть jupyter notebook+python. Это всё для немного других целей. Эту связку я использую, когда мне надо обработать условно большие массивы (от скажем 100 листов по 20 колонок) данных.
Заводить эту машину для того, чтобы быстренько обработать-посмотреть пару спектров не хочется. А в ориджине это всё несколько кликов мыши. +пара кликов сделать неплохой график в презентацию.
В вашей связке не сделаешь быстро красивых иллюстраций, достойного качества для публикаций в журнале. А если иллюстрация из нескольких графиков и панелей - то это уже мазохизм. Всё от экономии времени, на самом деле.
Я сам работаю в универе, и заменил Ориджин своей связкой Wolfram Engine и пара библиотек. Но! Почему я думаю что ориджин никогда не умрет и не будет заменен никакими питонами и прочим
Проприетарная система которая гарантирует что никакими обновлениями библиотек, питонов ее не сломать и она будет работать и будет работать с обратной совместимостью. Попробуйте запустить проект питона 10ти летней давности (а сроки в научных работах могу быть и больше легко): каких нибудь колес не будет, какие-то репы сменили АПИ, какие-то depricated. Ой, у нас система для построение 3D графики тянула библу с cdn которого больше нет. И это не лечится, это бардак во всем open source, это неприемлемо в научной среде.
Да, интерфейс может быть выглядит не оч. Но большинства не парит, научные сотрудники, особенно в возрасте уже имеют мышечную память на то, как сделать там фурье и тп. Научить молодого лаборанта/лаборантку примудростям программирования бывает очень сложно, ну прям очень. А бодаться с зависимостями и cli им еще тяжелее
Формат файлов Ориджин это все в одном. Графики, сырные данные и даже методы их обработки. Хотите запустить проект из 1999 на ориджин 7 - без проблем, все заработает гарантировано.
Из недостатков конечно пункт (1) ставит под вопросом все остальные. Ну противоречит это идеям хранения/распространения научного знания, что формат этот закрытый и его может открыть и редактировать софт частной компании. Которая в принципе может в какой-то момент сказать: все, закругляемся и тысячи файлов какого нибудь местного универа пропадут (исключаю возможность пиратства, так как это можно делать безнаказанно не везде)
В общем и целом, что Ориджин, что Эксель никогда не уйдут в долгосрочной перспективе.
Попробуйте запустить проект питона 10ти летней давности
формально, благодаря docker, venv и прочим современным фичам по управлению версиями, это уже не проблема. Да, будет проблема совместить старый и новый код в одном проекте (хотя нет, могу, inter process communications придумали давно, не говоря про банальный http), но и в замороженных проприетарных монстрах такая возможность в принципе не появится.
p.s. на самом деле проблему совместимости с версиями создает внимание, проприетарный продукт от nvidia (cuda-toolkit) за которым тянется много всяких зависимостей, и если что то перестает поддерживать ставшую старой версию cuda, то начинается цирк с конями и конфликты (спасибо venv на самом деле много проблем решает), а с открытым кодом у меня хотя бы принципиальная возможность что то подправить остается (помню как я какой то старый код правил чтобы он собрался в новых ос.... боюсь с проприетарными продуктами я даже помыслить бы не смог о том чтобы запустить этот код на современном железе,.. только виртуализация)
формально, благодаря docker, venv и прочим современным фичам по управлению версиями, …
Да это верно) Только вот научному сотруднику на это времени вряд ли есть разбираться. Как там compose файл делать и прочее. Если реально наукой заниматься, там просто нет этому места и времени. Обычно между делом: заливаешь там азот, есть пара минут посмотреть что там с данными, график построить попробовать на полученных данные. А если еще и это делать на beam time там вовсе фиксированное время, ночное или утреннее.
Исключение: если программирование как дисциплина нравится (мне скажем повозиться с докером в принципе ничего страшного).
научному сотруднику на это времени вряд ли есть разбираться
с таким подходом никакой эксель не спасет, а там где что то ваяют, потом разбираться и исправлять ой как дорого.
p.s. с venv (это опция python) не надо разбираться, оно просто работает, и решает миллион проблем из коробки (правда за счет излишка места на диске, если на каждый софт свое окружение создавать)
p.p.s. с docker формально тоже не нужно особо разбираться, весь интернет завален готовыми решениями чуть ли не на любой вкус, копируй, правь названия, работай. А уж с chatgpt это вообще легко.
И да, если ты дошел до жизни, что на твоей машине лежат скрипты 10-летней давности, и ты не умеешь или не желаешь учиться... то у тебя и ОС будет той же давности.
с таким подходом никакой эксель не спасет, а там где что то ваяют, потом разбираться и исправлять ой как дорого.
Видимо у нас разные представления о научных институтах. Нужен надежный инструмент, который будет работать всегда и без разницы на чем он работает. На самом деле мне интересно, работали ли в более менее серьезном НИИ или лаборатории, скажем типа HFML. Вот я работал, и отвлекающие факторы типа таких проблем с софтом это очень плохо. В реальности более менее серьезные физики они как раз пользуются максимум экселем/ориджином (потому что у них просто нет времени на другую фигню), PHD студенты, которые вероятно потом просто пойдут работать на завод либо останутся no-name пост доками как раз вовлекаются в другие технологии и дисциплины. У них может быть все красиво и современно и стильно, но они вероятно будет noname. Я не говорю что это правильно или хорошо, но по моим наблюдениям оно так и происходит.
И да, если ты дошел до жизни, что на твоей машине лежат скрипты 10-летней давности, и ты не умеешь или не желаешь учиться... то у тебя и ОС будет той же давности
Я понимаю к чему вы, я тоже стараюсь все обновлять. Но в целом вопрос: зачем? Как Windows 11 мне поможет больше грантов собрать, собрать мощный лазер. Если этот скрипт работает отлично и выполняет свою задачу, зачем тратить время и обновлять его без явной выгоды. Бред это все. Скрипты 10 летней давности появятся, так как какую-нибудь статью по фундаментальной физике надо писать лет 5 а то и больше. Материалов для исследований много, написал что-то, посчитал, переключился на другое. Через 5 лет возобновил. Вы просто не работали там и не видели внутреннюю кухню таких гигантов как Max Planck Institute и прочих.
А учиться уфф, какие-нибудь профессоры лет 80, которые используют Windows XP, еще как умеют въезжать в хайповые темы на страницах Nature и учиться, учиться и учиться.
Не поймите меня не правильно, все, что вы описываете это в целом хорошо, хорошая практика) Я сам же ей и следую, но большинству пофигу, и понятно почему, так как профит для их профессии почти нулевой в сложившейся десятилетиями системе.
Originlab хорош тем, что можно быстро построить красивый график.
Всё остальное - ДОЛГО.
В плане манипулирования данными до Экселя ему далеко.
В плане аппроксимаций - специализированная TableCurve значительно удобнее.
В Ориджине очень многое вроде есть, но где и как воспользоваться - неочевидно или долго
Обычно при подготовке статьи используется всё.
Ну понять товарищей из формулы-1 легко, фоис уже куплен, а за разработку нового софта или за настройку и внедрение существующего нужно еще платить, вот и результат. Гонщику лям заплатить не проблема, а внедрить нормальный софт жаба душит.
Подозреваю, что "нормальный" софт там сделать или купить там практически нереально. Все же, ф1 это ж полностью кастомная сборка. Все на исключениях, а не правилах. Никакие сапы и их аналоги, разработанные для заводов, делающих сотни тысяч одинаковых машин, под эти задачи не заточены. А разработка ERP системы с 0 это не миллионы, а десятки или даже сотни миллионов. Да и зачем это делать под единого заказчика? Врядли выйдет внедрить наработки куда-то ещё...
Может потому лям гонщику заплатить и не проблема - потому что все в экселе? А так - сервер БД купи, лицензии купи, софт купи, заплати за настройку, заплати за поддержку, заплати за сервера, создай ИТ отдел который все это будет обслуживать... Там и гонщику на лям уже не хватает.
то есть сейчас у них на макбуке экселька крутится, а как альтернатива сразу сервер, айтишники и т.п.? с чего бы вдруг? за поддержку экселя они платят? сервер экселя есть? зачем городушку городить?
Если уходить от экселя, то сразу делать так, что бы всем, кто причастен было удобно - а это уже какая-то ERP система получается. Одним ноутом не обойтись.
ну сейчас же обходятся, проблема экселя не в том что он не может справиться, а в том что это не то приложение которое закроет потребности. Сейчас любой ноут быстрее сервера 2007 года на Оптероне, учитывая что у нас там было оперативки 8 гб и работало 2500 банковских офисов - не думаю что будет проблема на современном ноуте поднять базу 1С. В будущем можно сервер арендовать и функции ИТ лягут на аутсорсера. Там вного всяких вариантов, зачем гадать.
Возвращаясь к Формула-1 то сомневаюсь, что они знают про 1С и поставят её, санкции и все такое. Но думаю тут проблема, что если им уж менять то сразу на современное. Подозреваю, что промежуточное, более подходящее, решение в виде того же местного аналога 1С с тем же ноутом отбросится со словами "зачем нам полумеры, менять то на современное".
Ну, такую статью можно вообще про любой софт написать: привести несколько примеров неправильной эксплуатации и парочку альтернативных решений. А по большому счёту, проблема лишь в кривых ручках, а в не в самом софте. А насчет "глючности" экселя так это и вовсе откровенное враньё: ошибки и потери данных, возникающие по вине пользователя, это не глюки софта.
Скажем так: на undefined behaviour-ы Excel богат, уж не знаю, баги это или фичи.
У меня была такая история: есть табличка с расписанием транспорта, одна из колонок - время, когда он перестаёт ходить. Excel почему-то решил, что в одной-единственной строчке должно быть не время, а дата-время.
И господь бы с ним, если бы он потом подчинился ручному указанию формата столбца или там замене строки - не, пришлось удалять лист целиком (!), копировать с резервной копии неповреждённые строки и вручную добавлять пострадавшую.
Оно, конечно, редко бывает. Но иногда очень метко.
Это не отвечает на вопрос, почему явное ручное задание формата уже после сработавшего автоопределения напрочь игнорировалось.
В Excel'е формат ячейки — это только форма внешнего представления. А когда ты копируешь что-то в ячейку, оно сначала преобразуется во внутренний формат, а потом показывается в формате ячейки (это две слабо зависящие друг от друга сущности). Изменение формата ячейки не изменяет внутреннее значение ячейки. В подобных случаях может помочь копирование ячейки в другую нетронутую форматированием ячейку с опцией "вставить как значение", чтобы увидеть, что там внутри.
Так очень сложно рассуждать, не имея конкретной таблицы перед глазами. Но я уже здесь писал, для работы с Excel'ем нужен определённый навык, просто тупо сесть за комп и считать, что Excel поведёт себя так, как ты хочешь, не получается. У него есть какие-то свои внутренние механизмы, только со временем понимаешь, что и как надо делать.
Например, если ввести в ячейку '25 то значение ячейки будет строка "25". И изменение формата на числовой не превратит это значение в число. Оно так и останется строкой.
Скажу больше - я пару раз попадал на undefined behaviour-ы, которые менялись в следующей версии. Т. е. ты привык, что в результате твоего действия Excel ведёт себя строго определённым образом, но в следующей версии он начинает делать всё иначе. Причём чтобы докопаться до настроек таких экзерсисов, нужно хорошо форумы пошерстить.
Полностью поддерживаю, эксель это самая уникальная и продвинутая программа для работы с таблицами и массивами данных. В ней просто огромный потенциал и возможности. Если уметь и знать все функции, то на основе этой проги можно вести учет огромных предприятий используя сложные формулы макросы и даже прямое програмирование. Эксель дает возможность работать с любыми данными и любыми типами данных и кодировок. Я даже в свое время писал программу в экселе для расчетов отчетности пункта металлоприема, и самое класное это графики, когда ты вносишь данные все мгновенно становится видным сразу на графике. Но вот в чем проблемма, в том, что это не специализированное по для таких дел и хоть там и можно это делать, есть специальные программы для подобных вещей, тот же 1с предприятие, гораздо лутше гугл таблиц, с раздачей прав и тп. По сути тоже эксель, только на максималках и специально для этого предназначенный. А все остальное, это кривые руки и непонимание того, как работает программа
учёт всех 20 000 комплектующих для сборки болидов ведётся в Excel,
всего то 20 000 - как там можно запутаться?
И ведь есть же sql, который гораздо старше ёкселя. Но когда в руках молоток, все вокруг кажется гвоздями
Эволюция. Или сценарий "лягушка в медленно греющейся воде", как больше нравится.
Была исходно простенькая табличка, в которой ломаться нечему было. Потом добавили признаков. И ещё. И ещё. Потом данных. Потом формул. Потом скриптов. Потом коннектов к другой табличке.
Пропустить (или отложить) момент перехода на БД, хоть какую-то, очень легко - ведь это отдельная работа, а операционка сама себя не сделает.
SQL в чистом виде может заменить малую часть экселя, и при том часто будет требовать больше телодвижений. К sql в большинтсве случаев нужен будет какой-нибудь питон.
Вы будете удивлены
Можно же из Excel подсасывать данные из баз данных. Т.е. большие массивы в БД, а все формулы и форматирование осталось в Excel. Хотя View я создавал как раз в БД, чтобы в Excel слишком много не тащить.
Помнится, с MySQL Workbench совсем красиво было. Даже редактировалось прям в таблице, лишь бы primary key был
Вы удивитесь, но есть аддоны по типу xltools, которые позволяют работать через sql/подобие sql с таблицами в excel
В 80-е годы компании покупали компьютеры, чтобы запустить электронные таблицы.
CALC и MS Works
НR: Как у вас обстоят дела с Ехсеl?
Я: Я его ненавижу.
НR: Понятно, то есть пользователь с опытом.
А почему libreoffice calc небыло в альтернативах?
А чем он лучше Excel?
Libreoffice местами пытается догонять ексель, но сам по себе довольно глючный - где-то читал что сообщество кодеров, пофиксив условную тысячу багов, походу дела порождает полторы тысячи новых багов.
Apache OpenOffice в этом плане намного стабильнее и надёжнее, но по функциональности наоборот - на порядок отстаёт.
Китайский WPS Office довольно приятный, но слишком навязчиво предлагает платные премиум версии. И с вводом формул у него проблемы - всё склеивает в одну строку.
А вот для совместной работы выбор невелик. В яндекс-диске онлайн бесплатно доступен платный импортозамещённый R7 Office (являющийся клоном Only Office, веб-аналога Libre Office), но он сильно уступает гугл-таблицам. Если же хочется независимости, то можно запустить на своём сервере например NextCloud, и уже в нем настроить совместную работу с документами Only Office. Но это конечно далеко не каждая домохозяйка справится.
OnlyOffice это не веб-аналог Libre office. Это самостоятельный продукт. Веб-аналог Либры - Collabora Office. Хотя это даже не аналог, это и есть либра, только с веб-мордой.
На счёт глюков не знаю, никогда всерьёз не пользовался, но вот тормозной он просто как что-то... На днях вставил в LibreOffice Calc таблицу, скопированную из браузера, размером 5 столбцов на 24 строки (всего-то 5х24, Карл!) - он ушёл в себя на несколько минут, непонятно было, выходить обратно собирается или нет. Таки прожевал, только первую колонку с картинками испохабил (не знаю, баг это или фича - вроде, ещё Excel не позволял вставлять картинки в ячейки, а только накладывать поверх). В какой-нибудь, прости господи, Obsidian, на каком-нибудь, прости господи, Электроне та же таблица вставляется моментально, моргнуть не успеешь, и совершенно корректно.
А вот для совместной работы выбор невелик.
Synology office полная копия гуглдокса.
Очень уж многое притянуто за уши, в большинстве проблем виноват не Excel, а пользователи, не умеющие с ним работать. Ещё забавно про 20 или 77 тысяч строк, мол это много для Excel - ну так для этого есть Power Query и Power Pivot, там спокойно строится модель данных и ворочаются миллионы строк. Но это требует навыков и умений. В конце концов, из этого вырос Power BI.
Насчёт глючности - тоже спорно, специально сейчас опросил коллег, по отделам, кто 80% времени с Excel (используется 2021 или 365 классический) работает - за последний год максимум пара сбоев на 2-3 десятка человек, да и те не критичные. Правда, тут в основном используются PQ и DAX + иногда классические формулы, но есть строгий запрет на макросы VBA (а, насколько помню, именно они раньше часто порождали сбои).
Но в целом, согласен - для каждой задачи свой инструмент нужен и инструментом нужно уметь работать. Всё-таки держать БД в Excel - не лучшая идея... ну а уж если жизнь заставила и держишь - хотя бы умей пользоваться и делай бэкапы))
Excel
Это Айфон в мире телефонов
А как вы сами для себя определите, где она, та самая граница, когда надо переходить от экселя к БД? :) Вот, так и пользователи.
"Надо задуматься" - когда понадобилось расшарить книгу как целое. "Надо переходить" - как минимум, когда ввод данных выполняешь не ты.
"Надо переходить" - как минимум, когда ввод данных выполняешь не ты.
А если данные вводит написанный мною макрос, то уже пора или еще не?
Да, пора, ибо этот макрос можно классифицировать как фронтэнд.
Это еще почему фронтэнд?
А если макрос (скрипт) запускает не человек, а он сам из таскшедуллера?
У меня десятки источников с формализованными данными (xls, xml, json, html, txt), которые приходят по почте, скачиваются с сайтов и локальных файлопомоек. Все это парсится и раскладывается в общий файл исходных данных (xlsb), откуда из него уже берут данные разные отчеты. Я с утра прихожу и открываю уже готовый результат, а также смотрю логи скриптов на предмет полноты и безошибочности. Где тут фронтэнд с макросом?
О как. Хорошо, уточняю формулировку. Когда владелец книги не имеет полного контроля над входными данными, если они лежат непосредственно в книге. То есть, можно использовать Excel-книгу в качестве средства визуализации данных при наличии внешнего источника данных как сущности Excel, потому что там уже (скорее всего) БД, и лучше мигрировать на БД, если какой-то кусок этой книги отдается на редактирование стороннему человеку. Собственные скрипты можно считать за собственноручный ввод данных, хотя и куда менее управляемый, чем набор, зато более управляемый, чем копипаста.
Когда владелец книги не имеет полного контроля над входными данными, если они лежат непосредственно в книге.
Вообще не понял. Контроля над входными данными у меня практически нет - большинство данных сторонние. Зато они генерируются софтом, а не человеком - значит там не будет лишних столбцов/строк, дерево xml не будет меняться каждый день и т.п.
если какой-то кусок этой книги отдается на редактирование стороннему человеку
Книга с данными вообще не подлежит редактированию человеком - с паролем на изменение ее открывает только скрипт, а люди - только на чтение. Книги с отчетами на основе данных - уже во власти того, кто готовит эти отчеты.
хотя и куда менее управляемый, чем набор
Тоже не понял. Что за набор Вы имеете в виду? Набор вручную на клавиатуре?
Вообще не понял. Контроля над входными данными у меня практически нет - большинство данных сторонние. Зато они генерируются софтом, а не человеком - значит там не будет лишних столбцов/строк, дерево xml не будет меняться каждый день и т.п.
Именно это и имел в виду. У вас есть как минимум sanity check и ограниченный входной формат данных, а большинство претензий к экселю в статье это его относительная свобода в преобразовании данных в ячейках "общего" формата. Когда данные тянет кто-то ещё, он может не так строго следить за форматом данных и потенциально исказить последующую работу с ними, включая влияние на соседние ячейки (сортировка, поиск, текст в формулы итп, с данными в экселе можно много фокусов выполнить).
Книга с данными вообще не подлежит редактированию человеком - с паролем на изменение ее открывает только скрипт, а люди - только на чтение. Книги с отчетами на основе данных - уже во власти того, кто готовит эти отчеты.
Прекрасный подход. Наверняка и бэкапы есть с приличной глубиной :) А книги с отчетами - уже не ваша сфера влияния, вы им data source а они сами парсят списки.
Тоже не понял. Что за набор Вы имеете в виду? Набор вручную на клавиатуре?
Да, именно, потому что при наборе данных идет потоковый контроль мозгами, как минимум, наборщик реагирует, если после набора текст в ячейке хоть как-то изменился. И если вдруг, скажем, набранное число не отскочило к правой границе, это повод его проверить. Имел я когда-то счастье работать с одной базой в виде экселевского файла, причём меня в открытом виде предупреждали, что затеешь автоматизацию - сам на ней повиснешь, воевал с форматами входных данных, с запросами на вставку в виде заполненного шаблона и их некорректностями (спасало то, что запросы были в виде отдельных файлов и был файл-рыба с заданными форматами и простыми проверками ввода), оценил и копипасту и ручной перенос, перенос оказался надёжнее. При правильной работе скриптов и отсутствии ошибок форматирования в их исходных данных заполнять файл скриптом ещё надёжнее, но в моём случае источником данных были люди, поэтому были проверки целостности на этапе вноса записей.
А книги с отчетами - уже не ваша сфера влияния, вы им data source а они сами парсят списки.
Нет, моя сфера. Данные я для себя готовлю, чтобы по ним мои же отчеты строились так, как нужно мне (начальству). Я создаю книги с отчетом (или другой обработкой исходных данных) и отдаю их подчиненным в работу.
Да, именно, потому что при наборе данных идет потоковый контроль мозгами, как минимум, наборщик реагирует, если после набора текст в ячейке хоть как-то изменился.
Блажен, кто верует. Глаз наборщика замыливается, он вводит то, но не в те ячейки, число не отскочило вправо, а он в этот момент чайку хлебнул и перешел к следующей ячейке.
Когда мне требовался ручной ввод, я делал таблицу на листе для ввода с кнопкой, по кнопке введенное из экселя преобразовывалось в xml и отправлялось по почте, а на стороне получателя скрипт разбирал xml. А здесь уже проблема число/текст решается просто: Val() или CDbl() либо возвращают ошибку, либо нет. То есть продолжал следовать своему принципу: в файл исходных данных эти данные заносит только скрипт. Человекам запрещено.
Ну и другой принцип, чтобы не бодаться число/дата/текст: если нет уверенности, то всё сначала в текст (например, xml), а потом разбираться.
А может честно напишем, что нету дешёвой замены? Вон, чуваки из Williams прямо сказали, что миграция на неназванную ERP была неимоверно дорогой и сложной. Ну да, потому что Excel на дюжину кладовщиков и трех с половиной менеджеров стоит копейки, за которые любой производитель "профессиональных" систем трекинга и закупок даже рекламный буклет не вышлет.
Дешёвой с точки зрения начальных инвестиций или операционных расходов после внедрения?
По второму пункту тот же Access будет не сильно дороже, а задачи те же самые вполне потянет. Но вот сам по себе переезд - это всегда дорого. Хотя бы потому, что нужны компетенции. Причём компетенции новые для команды, а это либо xN консультантам, либо в случае поиска in house - куча непоняток на тему "а кого мы вообще ищем?"
Вон, чуваки из Williams прямо сказали, что миграция на неназванную ERP была неимоверно дорогой и сложной.
Миграция на ERP - это, в первую очередь, анализ процессов. Собственно, львиная доля стоимости - это аналитика. Удобство ёкселя позволяет переделывать и дописывать на ходу, как дядя Фёдор письмо писал родителям из деревни. В результате, никто уже не знает, как и что работает, ничего, нигде и никак не документировано.
Неожиданно обнаружил еще проблему. Excel продолжает развиваться, для домашнего пользователя с Office 365 возможностей будет больше, чем для корпората с 2016 или ранее. В итоге модные и удобные функции будут недоступны из-за несовместимости.
Похоже, что вся статья - это реклама AirTable
Но в целом, дело не в Excel, а в менеджменте.
Явно звоночки начинались раньше. Если работник завода придет и скажет: "уже 10 тыс строк и сложновато искать", то большинство менеджеров ничего не сделают - решат, что это некомпетентность работника, а вся система ещё много лет предержется, и вообще, "денег на это нет, раньше же как-то работало" и т.п..
И когда это приведёт к проблемам, то менеджера уже не будет в том месте - на том месте их сменятся несколько штук, и ответственность никто не понесёт.
Тоже самое с дискетами в метро Сан Франциско. Или фортраном в банках.
и ответственность никто не понесёт
Я больше скажу — даже если менеджер останется, в лучшем случае его уволят. Но проблемы это никак не решит. К сожалению, у менеджеров ответствености никакой нет, одни лапки
Статья - скорее реклама Grist. Кстати, интересная софтина, обязательно попробую. Но логика перехода от критики Excel к Nocode-инструментам a-la Airtable вызывает вопросы, да. Всё-таки разные темы совсем.
Все оправдания в стиле - "это из за экселя" - это наивный детский лепет, рассчитанный на полнейших профанов.
Excel - это чрезвычайно удобный инструмент и обслуживает большинство задач где рано звать программиста. И поэтому потери при конвертации csv to xls - не разу не вина екселя (будто ни разу не сохраняли на диск и всё было в оперативной памяти), всякие компании/команды - болиды загнать в sql с простой админкой - это дело на несколько часов и остальное в том же духе.
Excel - это чрезвычайно удобный инструмент и обслуживает большинство задач где рано звать программиста.
И момент, когда надо позвать программиста, никто не замечает. Когда пользователь понимает, что программиста позвать таки надо, там уже такое нагромождение..
Excel - это просто идеальные говно и палки. Надо что-то накидать прямо сейчас, а процессы - это слишком сложно и, когда-нибудь потом. А потом будет море из костылей, граблей и квадратных колёс.
Программиста можно и потом позвать, а вот аналитика надо сразу.
Для аналитика может быть просто не быть задач такого масштаба. Это же эксель - каждый делает для себя, для своего участка и подразделения, для команды.
каждый делает для себя, для своего участка и подразделения, для команды.
Вот именно в этом и проблема. Получается лоскутное одеяло. Сначала его из лоскутов сшивают, а потом ещё поверх каждого лоскута нашивают лоскутов поменьше.
Excel — это рабочий инструмент, который не должен покидать пределы небольшой команды. Принимать снаружи или отдавать куда-либо можно только данные в оговоренном формате. По крайней мере всегда можно контролировать, что ты запихиваешь в свой Excel и что достаёшь оттуда. Допускать к нему каких-то людей извне чревато соответствующими последствиями. В случае с Excel'ем продукцией являются данные, а не программы. Программы ты производишь для себя и сам же употребляешь на свой страх и риск.
Excel — это рабочий инструмент, который не должен покидать пределы небольшой команды.
И у каждой команды свой Ёксель, итого несколько десятков тысяч чертей, команд, строк на листе.
В какой-то момент придёт понимание, что надо что-то делать с процессами - хотя бы, представлять себе. А никто себе не представляет.
Тут, конечно, рыба с головы гниёт. Если высшему руководству наплевать на рабочие процессы, то оно само пожнёт плоды.
Программы ты производишь для себя и сам же употребляешь на свой страх и риск.
Для себя, на свой страх и риск, программы и данные я произвожу у себя дома. На работе я ничего не делаю ни для себя, ни на свой страх и риск.
Давайте честно, если нет аналитика - то говна и палок можно наделать что в экселе, что в питоне, что на печатной машинке. И обвинять эксель в доступности так же глупо, как обвинять язык в том, что его используют неумело и нечетко формируя задания.
И момент, когда надо позвать программиста, никто не замечает. Когда пользователь понимает, что программиста позвать таки надо, там уже такое нагромождение..
Вы не работали в больших гос. конторах. Даже если вы знаете, что "вот сегодня" уже программист нужен, то вы ничего поделать не можете. Его не будет ни сегодня ни через неделю ни через год. Повезёт если вы не один такой, тогда Москва может зашевелится и скажет, что попробует решить проблему в ближайшее время. Через год после этого выдаст ответ "... данную проблему вполне можно решить используя Excel..."
Ну и вдобавок традиционные глюки с автоформатированием, из-за которого даже биологам приходится переименовать гены человека, такие как MARCHF1 (бывший MARCH1) и SEPTIN1 (бывш. SEPT1), чтобы Excel не принимал их за даты.
Переименовать гены вместо того, чтобы просто выставить текстовый формат ячейки?!
Копируем из текстового редактора число, например, «25.01» в Excel.
Получаем «25.янв».
Меняем формат ячейки на текстовый.
Получаем «45316».
Тихо, но выразительно материмся.
Удаляем всё, меняем формат, снова копируем...
И так, вы не поверите, каждый раз :)
Лично мне, в случае с моим «25.01», проще поменять всё там, в редакторе. Видимо, тем биологам – тоже.
Копируем из текстового редактора число, например, «25.01» в Excel.
Получаем «25.янв».
Меняем формат ячейки на текстовый.
Получаем «45316».
Естественно, формат ячейки надо задавать до копирования туда неформатированных данных.
Для бытовых задач такого рода рекомендую просто сохранять в CSV. Имхо, удобно.
Заполняешь таблицу, где-то с неправильным форматом, само не настраивается. Закрываешь эксель, открываешь блокнотом, правишь какие-то мелочи, открываешь снова эксель, работаешь с нормальными таблицами.
История о том, как оно есть пошло, описана выше.
«Файл» > «Параметры» > «Данные» > «Автоматическое преобразование данных».
Ну или апостроф поставить перед текстом, который не должен быть преобразован.
Но нет, мы лучше гены переименуем, чем будем учить матчасть.
«Файл» > «Параметры» > «Данные» > «Автоматическое преобразование данных».
Эта галочка появилась после вставки пистона второго размера. Но на желание простых юзеров изучать продукт, которым они пользуются, она почему-то никакого влияния не оказала.
Вот кстати тоже так делаю.добавляю спецсимвол для тех ячеек,которые должны быть только в том виде,который введен и ни в коем случае не изменяться.
А вообще плотно работаю в команде в office 365 и google sheets.давно ловлю себя на мысли,что майкрософт и гугл это как andriod и ios. Постоянно копируют фишки друг друга,что в принципе хорошо
Статья очень напоминает незабвенные научные анекдоты о вреде огурцов и об опасном веществе дигидрогена монооксиде.
Естественно, чем больше установок Excel в мире, тем больше операторов и пользователей, которые допускают ошибки при пользовании им. На мой взгляд, для решения этой проблемы пора переходить на Fruit Mix Office. Насколько мне известно, электронные таблицы Fruit Mix Calc не приводят к ошибкам. Потому что его не существует
Как пользователь Excel, erp-систем и прочих специализированных решений. У компаний интеграторов ERP встречал внутренние документы в какие места не стоит лезть со своими предложениями. Своими словами, если у потенциального клиента настроена отчетность и аналитика со сбором данных в сводных таблицах Excel, то не пытайтесь это изменить, в конце концов вы потеряете клиента.
Я со многими ERP-интеграторами общался и сам вышел из них в конце 90-х. Чтобы сбить спесь насчет excel, показывал аналитику бюджета одного из текущих проектов excel, а потом просил повторить в своей системе. На этом попытки впарить модуль бюджетирования с платежным календарем прекращались.
Для меня бухгалтеры - это операторы. Бесполезно нагружать их функционал еще управленческой отчетностью, они живут в реальности беспроблемной сдачи отчетности в налоговую, в том числе главбух. Не самая простая работа.
Выстраиваешь процессы по ведению нужной аналитики, совершенно не нужной бухгалтерии и другим корпоративным структурам, но за отсутствии которой при разноске документов могут "мотивировать". А потом эту информацию агрегируешь и выгружаешь в excel.
Если у тебя с десяток компаний с 3 типами систем, одна из них 1С с зоопарком конфигураций и версий, то в чертогах разума уже давно стоит алтарь с первой коробкой Excel и вечно горящей свечой.
У нас в SAP была Z доработка по бюджетированию и платежному календарю. Для РН с тысячей бизнес единиц и сотней тысяч пользователей. Под такую нагрузку вообще других ерп систем нет.
Я говорил про гибкость, а не жесткий операционный бюджет. У меня было с десяток проектов, где статьи бюджета в одном случае группируются одним способом, а в другом иначе. И проект может вестись год, а потом переводится в статус работающей бизнес-единицы, либо закрывается. Вся структура и логика хранится в отчетности(Excel) и нет остатков справочника иерархии проекта с ненужными статьями в системе. Особенно, если это работает лет 20. Про проблемы захламленных скелетами справочников не мне вам объяснять.
Excel не для одновременной работы тысяч бизнес-единиц в одном файле и связанных файлах. Это инструмент небольшого отдела, где все контролируется руководителем подразделения, либо топ-менеджером.
Не тема этой статьи. Большей части предприятий не нужен SAP, не тот масштаб. Я не знаю что такое PH, но общался с представителями российских компаний из нефтяного и газового сектора, где стоял SAP для инвесторов, а за фасадом работали на 1С и Галактике. Например, Транснефть, Лукойл, Роснефть, да вы и без меня знаете.
РН это как раз Роснефть и есть ) Да, 1с там тоже много где, но сводится все в сап.
А бюджетов там два независимых дерева. Я сам за два года в точную архитектуру не въехал.
Я именно это и написал, вся работа ведется в других системах. А потом для МСФО все сводится в SAP и Сечину раз в квартал(год) показывают отчет. Я сводный отчет могу и в excel вести и настрогать. Нет в подобных "архитектурах" вертикальной настройки бюджета сверху вниз через SAP, только сбор итогового данных в виде отчета.
В статье не хватает дополнения: Excel сам виноват, вечно новые фичи прикручивает, а потому каждая домохозчйка его юзает как ни попадя!
Заголовок, как и текст, для сбора комментариев. Сам рейтинг может быть отрицательным, но откликнутся многие. Личное мнение. По тексту...
"20000 комплектующих", но "сотни тысяч компонентов". Использовать старую версию, у которой есть ограничения по количеству строк, можно. Но нужно и знать об ограничениях.
"JP Morgan Chase чуть не обанкротился"... Данные переносились вручную, но виноват Excel?
Barclays vs Lehman Brothers... Excel должен был догадаться, что эти строки нужно удалить, если они скрыты?
И про комментарий "число 25.01" и плохость Excel из-за этого... Вы авторучкой как пишете не целые числа? Через запятую или через точку? Я пишу через запятую. В повседневной деятельности регулярно заменяю "." на ",", убираю " " между разрядами. И мысленно ругаю тех, кто отправляет данные для сотни получателей в таком формате. Но это ни Access, ни DBF, ни Excel не виноваты.
Использую Excel больше четверти века, очень большое подспорье в работе, обладающее большой гибкостью. Да, у него есть свои особенности, которые нужно учитывать при использовании. Но говорить, что у него нет своей сферы применимости, я бы не стал. Далеко не все задачи целесообразно автоматизировать, как по цене, так и по качеству. Просто использование Excel'я требует определённой квалификации. Мы же не вручаем медсестре скальпель и не отправляем в операционную. А если и отправим, то вряд ли станем утверждать, что скальпель виноват во всех огрехах. А то можно было бы громогласно заявить, что скальпель — самый опасный инструмент на планете.
Сейчас даже на ум не приходят какие-то особенности Excel'я, которые мешали бы жить. Единственная ошибка, которая приходит на ум и которую они, наверняка, уже никогда не исправят — наличие никогда не существовавшей даты 29.02.1900.
Это вы еще про Power BI забыли 🙂
краткий пересказ: утюг самый опасный предмет - куча людей им обожглось!!!
уже 25 лет работаю в экселе. ненавижу такие статьи.
У этих таблиц сильно ограниченная функциональность, по сравнению с Excel, зато есть важное преимущество: возможность совместной работы.
С каких пор возможность совместной работы из экселя исчезла?..
Столько примеров против екселя накидали, а самого важного - округление до 15 символов после запятой, не упомянули. И особенно удивительно, что Ексель так плотно сросся с финансовым миром при таком дефекте.
В смысле округление? Там же обычный double, что с ним не так?
А зачем в финансовом мире, где минимальная единица - цент/копейка, округление до 15 символов после запятой?
Смотря что считать. Если какие-нибудь деривативы обсчитывать, то вполне нужно. Но там обычный double, я не понял претензий.
Отвечу сразу на ветку. Хочу отметить, что я так же активный пользователь Ексель, мой комментарий больше к тому, что удивительно, что в статье столько примеров где очевиден человеческий фактор, но не упомянули такой технический момент.
Касательно округления, да, верно подмечено, дело в double. Проблема в том, что он несколько непредсказуемо/неочевидно себя ведет. Наглядный фокус - посчитать 1/3, скопировать как значение и умножить 3, то мы увидим получим 0,999 с 15 знаками в мантиссе. Если поделим еще на 100, то будет 0,00... и 15 девяток. И главное, мы скорее всего этого не заметим, тк будем видеть 1 и 0,001, тк не раскроем достаточно знаков.
Касаемо финансового мира. Особенность копеек в том, что они складываются в миллионы, миллиарды и тп денег. А в этих случаях возникает желание повысить разрядность. А там еще добавить какие-нибудь курсы/валюты и внезапно окажется, что распределение бюджета в 1млрд денег не равно распределению бюджета в 1 000 000 000 денег. И это все в сегменте пользователей где не так много осведомленных про тип double, и при этом также радеющих за учет каждой копейки.
А Вы на практике работали с такими данными? Вот я работал, и как раз в Excel, и скажу, что проблема надуманная. Те подразделения банка, которым нужно считать точно, считают с той точностью, с которой требуется (если речь о курсах, ставках, и т.п.). Я не видел случая, когда требовалось бы больше 15 знаков. Бухгалтерам эта точность не нужна, они проводки делают с точностью до копеек и вообще экселем не пользуются, эксель не потянет бухгалтерию банка, у них специализированные программы.
P.S. Я попробовал 1/3 умножить на 3, у меня получилось ровно 1, без девяток.
Отвечу выдержкой из договора
2.4. Точность расчетов и принципы округления
Объемы электрической энергии в соответствии с настоящим Регламентом рассчитываются в киловатт-часах с точностью до целых.
Величины мощности в соответствии с настоящим Регламентом рассчитываются в мегаваттах с точностью до трех знаков после запятой (до киловатт).
Величины финансовых обязательств/требований (в том числе штрафы и денежные суммы) рассчитываются в рублях с точностью до двух знаков после запятой (до копеек).
Цены по договорам комиссии и купли-продажи на РСВ и БР указываются в руб./кВт×ч с точностью до 11 знаков после запятой с учетом возможности средств отображения (Microsoft Excel). Прочие расчетные цены, определяемые в соответствии с настоящим Регламентом, указываются в руб./кВт×ч с точностью до 11 знаков после запятой, с учетом возможности средств отображения (Microsoft Excel).
Цены по договорам купли-продажи мощности рассчитываются в руб./МВт с точностью до 11 знаков после запятой, если Договором о присоединении к торговой системе оптового рынка не предусмотрено иное. При этом цены по договорам купли-продажи мощности указываются в руб./МВт с точностью до 11 знаков после запятой с учетом возможности средств отображения (Microsoft Excel), если Договором о присоединении к торговой системе оптового рынка не предусмотрено иное.
У меня было так
Описанные в статье траблы являются следствием долгого исторического развития. Конечно, обвинить людей в неправильном использовании инструмента, - это легко, только у этого есть объяснения, которые говорят о том, что по-другому оно быть в данном случае и не могло:
Большинство файлов (которые по сути уже базы данны), изначально не рождались в таком объёме, они исторически выросли до этих размеров из маленьких табличек.
Раздувание массивных файлов, - это следствие того самого низкого порога вхождения в "базы данных". То есть, если секретарша смогла в таблицу 4*5, она очень просто экстраполировала свои скиллы на таблицу в 77000*500, которую и создала. Тут можно привести аналогию с человеком, который однажды положил в свою легковушку два ящика пива, а через пять лет понял, что на ней можно перевозить 1000 ящиков, потому что есть не только салон и багажник, но и крыша, а также два прицепа.
Эксель не умирает и долго не умрёт ещё и потому, что у него просто космическая компатибильность: файлы 20-летней давности легко открываются на современном компе практически в любой ОСи да ещё и разными программами (не только от МС).
Одно не очень понятно: зачем в статье предлагается "эксель, только помощнее". Это не решает задачу, потому что предлагает лишь более мощный инструмент. Это лейкопластырь эдакий. Грист не будет тягаться с базами данных на миллиарды строк, это понятно, то есть лишь отложит решение проблемы. Кто бодался в экселе с 100.000 строками, будут юзать грист, чтобы у него эти 100К строк летали и даже дорастёт до 10 млн строк, но потом упрётся в ту же проблему, потому что она не решена.
зато есть важное преимущество: возможность совместной работы
А разве в Excel нет возможности совместной работы?
Excell легко использовать в системах, где нужна генерация документов из данных БД из программ или даже по SQL запросам из БД . Поддержка OLE automation позволяет создавать отчеты и документы достаточно просто не используя какие либо генераторы отчетов в программах, что удобно для пользователей которые получают редактируемый документ и возможность сохранения его в компьютере. Я в общем достаточно много этими возможностями пользуюсь в своих разработанных и разрабатываемых системах и это удобно.
Прикольно то, что в свое время над Excel работал Гейб Ньюэл, который потом создал с партнером valve и half-life.
Я помню даже клип, где девка отправляла email с помощью Excel'я и ждала ответа. Воистину могучий инструмент.
Google Sheets. У этих таблиц сильно ограниченная функциональность, по сравнению с Excel, зато есть важное преимущество: возможность совместной работы.
автор, Вы просто не знаете всех возможностей Google Spreadsheets.
Начиная от тесной интеграции с всеми сервисами Google (почта, календари, ИИ и тд.), создания собственного web (или API)-сервера, заканчивая возможностью создания Addon.
Ну тут же проблема не в Excel, а в управленческом подходе - что в редакторе таблиц, по сути, бухгалтера пишут бизнес-критические enterprise-приложения. Это из разряда "вчера после пьянки блевал, наверное кока-колой отравился". И Google Sheets вовсе не альтернатива и не замена Excel в данном случае. Правильной альтернативой тут может быть только принципиально иной подход, как архитектурный - так и управленческий, методологический и т.п. Ну то есть критичные данные и сложная логика должны создаваться и управляться по методикам, которые гарантируют безопасность, отказоустойчивость и т.п., нужны подходы по тестированию, проектированию, депоойменту и т.п. А просто перенести 200к строк из экселя в гугл - ну получите те же косяки, только со корпорацией добра 😆
Слушайте, ну это какой-то треш, а не статья, как по мне! Мерить сложность в строках данных, которых 77000 - это такое себе. А говорить про Excel, как про "инструмент, в котором можно сделать что угодно", хотя в нём нельзя нормально прозумить туда-сюда график - это надо сильно постараться натянуть сову на глобус!
ещë одно ограничение забыли: нельзя открыть два файла с одиноковыми короткими именами. и смех и грех.
Профессионалы Excel знают, что c формулами, макросами, VBA и лямбдами его функционал практически безграничный. С лямбдами стали доступны циклы и рекурсия без использования VBA. Есть ещё динамические массивы, произвольные типы данных и др.
На что только не идут, лишь бы не пользоваться "нормальным" ЯП
Посоветуйте workflow пожалуйста.
Типичная задача, которую решают в Excel - ввели данные, все пересчиталось, отобразились всякие пивоты, графики. При этом мелкие изменения вполне может делать пользователь. Ну т.е. некто нафигачил "вычисления с лямбдами". Теперь пользовтель накладывает на них свои фильтры, делает свои выборки, форматирует, как ему надо и т.п.
Какой нормальный ЯП вы предлагаете и в каком качестве?
Если там именно каша из формул, макросов, VBA и лямбд с циклами и рекурсией, динамическими массивами, произвольными типами данных и др., как указано в исходной цитате - я бы просто выкинул это все на помойку и переделал на JS / PHP / C / python / ... + любая СУБД. Да, больно. Да, пользователи будут ругаться и привыкать к новой программе. Зато можно масштабировать и поддерживать.
Если цель - не трогать содержимое этого дурно пахнущего болота и не показывать людям, о чем тогда вообще речь?
Как я уже писал, "кто-то нафигачил всяких формул" и
Теперь пользователь накладывает на них свои фильтры, делает свои выборки, форматирует, как ему надо и т.п.
К какой программе пользователям придется привыкать? На ЯП предлагаете реализовать создание новых сводных таблиц?
Можно, конечно, оставить Excel в качестве фронтенда к СУБД. Разбиваем на куски ввод/вычисления/отображение? Тогда логичнее использовать PowerBI. Хотя некоторые таблицы (выделить конкретную ячейку не только цветом, но и особым бордером...) мне (и, тем более пользователю) проще в Excel.
Ненене, никаких "оставить Ексель в качестве фронтенда" - имхо - это соберет недостатки и "вашего" и "моего" вариантов.
Вы и я обсуждаем какие-то разные сценарии. Для меня <произвольные типы данных> в ячейке, <рекурсия> - прям красная черта для Ексель таблиц. <Динамические массивы> тоже красный флаг. Как это барахло отлаживать, тестировать и искать ошибки? У вас эти вещи реально используются в Екселе?
Я совершенно согласен, что вот это вот все в Excel делать тяжко. Даже просто длинные формулы и то сложно. Условно говоря, я сперва делаю части в разных колонках, по отдельности их отлаживаю, потом собираю в кучку в одну колонку с длиннющей формулой.
Ничего в этом хорошего нет. Но как заменить фронтендовскую часть, где пользователь из готовых таблиц, куда он не лезет, собирает свои собственные, в т.ч. сводные, форматирует, в том числе с условиями, фильтрует, строит графики - слабо представляю.
Собственно поэтому и выбирают Excel. Его недостатки работы с формулами - паровозик от отсутствия выбора пользовательской части, механизмов отображения, а не сам критерий выбора.
P.S. Хоть в Excel/PowerBI и есть возможность делать Web запросы в PowerQuery и всячески полученные JSON преобразовать, я по возможности взаимодествие с внешними API делаю через Python скрипт, возвращающий pandas dataframe непосредственно изнутри платформы. Но дальше все стандартно. Powerquery, DAX...
Не вижу ничего уникального в перечисленном функционале. Я на архитектуру больше смотрю. Исключительно вопрос компьютерной грамотности и степени текущей попоболи от экселевского велосипеда с костылями.
Когда-то и с бумажных отчётов с калькулятором тети из бухгалтерии переходили на цифровой с воплями и страданиями. Юзер так привык и по-другому не может. Жизнь заставит - научится.
Конечно, у экселя есть своя ниша, с этим глупо спорить.
Excel — самый опасный софт на планете