МойОфис хуже, чем Microsoft Office. Например таблицы в МойОфис сильно тормозят, особенно если речь идёт о таблицах, например, в 20 тысяч строк и больше. Я пользовался 1 день и понял, что МойОфис не сможет заменить мне Microsoft Excel.
Поэтому, считаю проблему компании МойОфис не в управленцах, а в программистах.
Сколько поставщиков знаю, все отправляют прайсы только в Экселе. И какие ты более эффективные инструменты знаешь для взаимодействия между магазинами и производителями?
Ладно я умею пользоваться СУБД, могу составить запрос SQL, а подавляющее большинство моих конкурентов такое сделать не смогут. И че теперь производителю им не реализовывать товары?
Ну а теперь подумай почему они так делают. Что мешает производителю (судя по объемам не мелкому) сделать нормальную систему документооборота для своих клиентов? С выборкой товара по фильтрам и категориям, выгрузкой в различные форматы. А если уж по нормальному - то вообще API, по которому клиенты смогут забирать нужное например сразу в 1с.
Товарищ живёт в ЕС, закупает на каком то заводе всякую фурнитуру типа дверных петель, защёлок и по. мелочнвки хозяйственной. Так вот у завода поставщика именно такая система - есть личный кабинет и API. Программист за пару дней прикрутил все к его системе учета. Пару кликов мыши и прайс обновился. Причем от производителя тоже могут быть скидки на товар и вот это все сразу учитывается. Ни надо ни с кем созваниваться, договариватся а потом ещё и файлики править.
мелкому производителю помешает сделать это цена на разработку. да, для крупной или гос. компании заплатить 100-200 миллионов за разработку, тестирование и ввод в пром апишки не проблема, а вот частнику оно нахрен не упёрлось. И не надо тут говорить, что 1 толковый разработчик напишет ему это всё, со всем этим функционалом за условные 500 тысяч-лям. внезапно - это два-три месяца работы синьора на вольных хлебах(галеры выставляют нереальный для частника ценник, при этом ты не застрахован от решения на фекально-дендральном стеке), а сначала надо нормальную аналитику накатать, оттестировать решение, выкатить в пром, прикрутить какой-никакой мониторинг, поддерживать это всё. зачем - если есть готовое решение в виде экселя с той же самой функциональностью?
Это все условности в ваше голове. Так или иначе любой производитель уже ведёт каталог продукции, а значит создать сервис на основе этой базы/выгрузки вполне под силу. Ничего там такого сверхъестественного нету. И да,это вполне по силам нормальному сеньеру, даже без аналитика, за разумный срок. Уж крупный производитель вполне осилит пару тройку разрабов. Да и кто то у них содержит ИТ, и поднять докер с парой сервисов вполне по силам даже админку толковому - ничего там мудреного нет.
В общем это просто не желание/не понимание сделать нормально. Проще же содержать нескольких менеджеров, которые будут ручками обновлять, ошибается. Им будут бесконечно звонить заказчики, уточнять позиции, возмущаться что в прайсе естьч по факту нет, т.к. девочка проехала позицию. Ну да,это же хорошо выглядит - бурная деятельность и похер что КПД к нулю стремится. В свое время когда отвечал за закупку офисной техники, заебала такая вот контора с вечным бардаком с прайсами - нахер их отправил и ушел к другим поставщикам. Даже откат мне их не всрался.
А мелкие производители могут пользоваться готовыми сервисами. Гугл в помощь - полно всяких. Но там же целых 5 тыщ в месяц платит надо! Не, мы лучше обезьянью работу делать будем в Экселе,который внезапно нихрена не имеет той функциональности что нужна. Так, лишь лёгкое облегчение типа авто фильтра.
Автоматизировать иди нет - дело сугубо личное. Если я вижу что на сайте нет цены, типа звоните уточняйте - сразу нахуй. Понятно что этот геморрой будет. Начнут выяснять, потом ещё пять раз поменяют в итоге просто время потеряешь. То же самое и обычными магазинами - не могут сразу сказать цену - идите нахер.
В Экселе есть очень удобная функция - ВПР. И остатки можно с помощью нее вычислить, добавить в прайс проданное.
Вершина автоматизации - Excel. Может тогда выкинуть нахуй все эти питоны, мл и прочее, ведь это дорого, геморрой, проще ручками сделать быстрее. Ну или в ход пустить тяжёлую артиллерию - ВПР.
Нахуй вся эта OLAP аналитика с расчетом нарастающих итогов и с разбивкой по регионам и товарным группам)
Для автоматизации я применяю Delphi 7 (да, до сих на нем пишу, по мне намного лучше питона), php, Android Studio (Java). Если мне нужна аналитика по продажам, то я запускаю уже давно сделанную страницу php и она мне выдает нужные мне таблицы: что и сколько докупить, чтобы на месяц хватило, сколько заработал сегодня, вчера, за неделю, месяц, год, сколько чистыми, сколько с налогами и комиссиями и так далее.
Другое дело, когда мне поставщики скидывают прайсы только в форматах Эксель. Не вижу проблем за пару минут сделать заказать с помощью ВПР.
Так, ну ок, на самом деле я не кидаю никакие камни в ваш огород, тем более, если у вас бизнес (любой), то вы явно на ступеньку смышленней и выше меня, и уж точно не мне говорить что и как должно быть автоматизировано. Да хоть это из говна и палок сделано, главное чтобы оно работало и оправдывало вложения.
Расскажу небольшую историю про случай в одной крупной компании (понятное дело, я не буду называть в какой). Я рассказываю потому что, я к части условных активностей, описываемых ниже, имею почти прямое отношение, но часть я слышу, как это говорится "краем уха". И да, я некоторые обсуждения менеджеров не знаю, но я сужу по всему благодаря тому, что я собираю кусочки информации и на основании этого делаю вывод, поэтому если вдруг кто-то считает что "краем уха услышал - это не канает, ты там что-то додумал" - на это отвечаю - пошли нахуй. А Вы почитайте её с точки зрения того, кто за весь этот концерт платит.
Смотрите, ситуация.... На самом деле, я сейчас понимаю что трудно придумать аналогию, но буду стараться как могу. И давайте может, постараюсь "притянуть за уши" ваш пример.
Вот у вас есть деятельность - выставление заказов, по прайсам от поставщиков. Предположим, у вас есть какая-то методология... Ну там:
1. Принять прайс
2. Оценить его, вычистить мусор
3. Сложить в свою базу
4. Проанализировать, выбрать лучший товар, и сделать заказ.
И дальше, представьте... У вас есть две команды (наверняка для вас это непозволительная роскошь, но, представьте).
Одна команда - это IT. А вторая команда - это ваши пользователи (для айти - это бизнес-пользователи, заказчики, ну или как хотите их называйте). И тут нужно сделать еще одно допущение - ваши бизнес-пользователи - не просто умеют по телефону лялякать, а они еще и на питоне захуярить что-то могут, в базах ебашут на SQL на право и налево, и могут организовать бизнес-процесс на одних хранимках T-SQL (PL/SQL, pgPLSQL, да похуй... короче, на любых).
И ваши пользователи, в рамках выполнения цели по задаче - могут наебашить что-нибудь на питоне, потом, они еще не гнушатся взять трубку и позвонить поставщику лично... Узнав детали, они ручками что-то правят в Excel. И на выходе, для получения конечного результата, ручками забивают определенные цифры в "заранее подготовленный лист на котором готовы все формулы".
Параллельно сидит команда IT и хуярит на Java супер-энтерпрайзное решение, которое автоматически под нагрузкой умеет "в параллеле" обрабатывать много каталогов от поставщиков и автоматически делать все действия (4 шага) - описанные выше. При этом, когда команда IT слышит, что команда заказчиков, пока ждет (оооочень долго ждет) готовности разработки всех задач, которые им нужны, чтобы эффективно выполнять вышеописанную методологию из 4 шагов, параллельно побыстрее автоматизирует части шагов на питоне, а что-то и просто в Excel руками делают, то команда IT даже чуть ли не смеется над командой заказчиков, типа "ебать они долбоебы, пиздец, автоматизация в Excel, ну это же пиздец, у нас же тут Java, Kafka, микросервисы, spring.... А они дурачки всё по старинке в Excel делают".
Идут годы (да, годы). И команда заказчиков как-то уже привыкла к своим поделкам на Python+Excel, а команда IT все доделывает свой монструозный продукт (но со всеми атрибутами пиздатости, аля кафки, спринга и прочего говна). И постепенно уже руководители бизнеса начинают задаваться вопросом, мол, а нахуя козе баян как говорится. Мы тут платим дохуя бабла чтобы у нас тут все было как в энтерпрайзе, и кафки и спринги, но оно все не взлетает и не взлетает... Причем бизнес видит, что пользователи, которые хуярят на питоне выдают задачи быстрее чем IT.
Ну и так как это большая корпорация с "нетоксичным коллективом", то ни у кого смелости не хватает сказать - это всё полное фуфло, выкидывайте это говно, ваша джава говно, нихуя не работает, кафку тоже не можете настроить - собрали вещи и проваливайте нахуй отсюда, не занимайте места и не тратьте ФОТ.
Вместо этого начинается все "из далека". Бизнес начинает предлагать всякие штуки. Например, бизнес говорит - а давайте что-то сделаем чтобы можно было и вашей штукой пользоваться, и чтобы пользователи на питон могли бы быстро прогонять скрипты свои. В ответ IT отвечает что мол - мы подумаем, бла бла бла. Но, у IT явно не видно желания пачкать руки в этом гов... питоне, поэтому IT как-то сводит такие подходы на нет, потому что это не ынтырпрайзно... ниправильно... Ну и можно там до кучи, не соответствует паттернам-хуяттернам каким-нибудь, или там, не соответствует методологии SOLID (ну или не методологии, а как эта хуета называется), KISS и прочие прочие умные словечки, зная которые можно набить себе зарплату повыше.
Ну и на финальной стадии, приходит бизнес со следующим предложением. Дальше, я приведу пример разговора одного человека, который, назовем так - главный по Java в проекте со стороны IT и кого-то со стороны бизнеса.
Тут я могу почти как цитату привести ответ главного по Java, во время разговора по телефону с одним из представителей бизнеса с другой стороны. А то что сказал представитель бизнеса - я могу только предположить, но из ответа главного по Java это следует.
Так вот, восстанавливаем примерно разговор. У нас два действующих лица, назовем их - Java (J) и Business (B).
B: Привет, ну что, давай обсудим основные направления развития системы
J: Хорошо, давайте.
B: Видите ли... Мы посмотрели на общие результаты команд за прошедшее время, и увидели что наши пользователи на питончиках вроде что-то выдают, а вот на Java система все дорабатывается и не успевает за потребностями бизнеса
....
B: И у нас родилась идея. С учетом вышеизложенных факторов, мы хотели бы предложить, чтобы ваши разработчики тоже бы занялись бы питоном, и вместе с нашими бизнес-пользователями они выдали бы еще больше результата...
J: Нет нет нет... Этому не бывать. Вы хотите чтобы разработчики на Java начали переквалифицироваться в разработчиков на питон. Этого не будет, мои разработчики не будут этого делать. Посмотрите на зарплаты Java разработчиков и на зарплаты Python разработчиков. Для моих разработчиков этого будет даунгрейд, никто не будет этим заниматься.
--------------------------------------------------------- END ----------------------------------------------
Конец истории....
Интересно Ваше мнение, со стороны бизнеса )))
По-моему похожие ситуации происходят повсеместно. Например, я менее чем за год уверенно стал писать на php только потому что модули для 1с Битрикса приходилось допиливать самому, иначе от разработчиков не дождешься. А если почитать комментарии к модулям 1с Битрикс, то приходишь к выводу, что большая часть пользователей 1с Битрикса тоже допиливают функционал этих модулей самостоятельно.
Что касаемо Java и Python, то зачем разработчикам изучать Python и писать на нем,если можно сконтачить их и другими способами? Например, Delphi 7, на котором я сейчас в основном пишу, не умеет работать с протоколом HTTPS. Раньше таких проблем не было, поэтому я на нем раньше даже парсеры писал. А теперь многие сайты работают на HTTPS. Приходилось заказывать парсеры на фрилансе. Писали мне на питоне. На выходе была таблица с кривыми данными, а формат не соответствовал расширению.
Поэтому, я написал программу на Делфи, которая запускала прогу на питоне. Как только программа завершала парсинг,моя программа меняла расширения файлов на правильное,запускала bat файл, в котором поочередно преобразовывались файлы из xlsx в xls при помощи консольной программы. Это делалось, чтобы не применять OLE. А потом прога анализировала и переделывала данные правильно.
Аналогично проделывал с API. Мне надо было новые товары загружать в кассу через API. Для автоматизации процесса. Но это можно сделать только через HTTPS товароучетной системы. А Делфи так не умеет. Поэтому я написал php скрипт, который работает с API. Получилось так:
Программа на Делфи архивирует данные о более 20 тысячах товаров (1 секунда) и загружает на поддомен моего скрытого сайта по http (2 секунды). После загрузки это все разархивируется скриптом php. Далее программа на Делфи запускает скрипт,который отправляет данные по https по API (2-3 минуты).
Ваши разработчики могли бы написать ПО так, чтобы оно могло обрабатывать выходные данные, получаемые от ПО, написанного на питоне. Или автоматически запускать эти программы, а потом обрабатывать полученные данные
Хаха)
Там схема немного сложнее у нас (ну конечно, да, этож ынтырпрайз, хахаха).
Исходные данные и для питонов и для нашей Java - одни и те же. Лежат в одном месте. И к ним обращается и Java и Питоны.
Разница в том, что Java - это тырпрайз со всеми вытекающими, релиз-процесс, и вся остальная хуйня, а питон - это наколенные поделки, без релиз-процессов и прочего, за счет чего, получается что согласно процессам на Java функциональность выводится минимум за полтора месяца. А на питоне могут то же самое написать за пару дней)
И суть в том, что, бизнес-пользователи, тестируют, по сути, с помощью питона всякие подходы, и просят нас это запрогать уже в тырпрайзе...
Но скорость изменений настолько высока, что они что-то оттестировали, пришли к нам, типа мол - вот хотим синюю полупрозрачную ленточку... Мы говорим - да окей, ближайшая поставка - через полтора месяца. Все, по рукам.
Но через неделю выясняется, что синяя полупрозрачная ленточка - это полная хуйня, нужна красно-оранжевая. Но, производственный процесс запустился на синей ленточке, и остановить это сложно. Конечно, бизнес подойдет и скажет что синяя полупрозрачная ленточка - это уже хуйня, и нужно ориентироваться на оранжевую. Но, методологи от IT докажут и расскажут бизнесу, в очередной раз о том, что надо "ЧЕТКО ПОНИМАТЬ ЧТО ТЫ ХОЧЕШЬ" и "ПРИХОДИТЬ С КОНКРЕТНЫМИ ПОСТАНОВКАМИ И НЕ МЕНЯТЬ ИХ НА ХОДУ". В итоге, бизнес будет какое-то время мириться с этим. Но параллельно он попросит своих пользователей в очередной раз на коленке на питоне поправить пару строк, чтобы в итоге это была красно-оранжевая полупрозрачная ленточка. И это сделают за пару дней.
А потом вот на таких созвонах, на предложение "всем перейти в питон" будут слушать возражения в стиле "ПОСМОТРИТЕ НА ЗАРПЛАТЫ JAVA-РАЗРАБОТЧИКОВ и PYTHON-РАЗРАБОТЧИКОВ, ЭТО ПОТЕРЯ КВАЛИФИКАЦИИ и ЗАРПЛАТЫ".
А ведь бизнес смотрит на это, и видит.
1. Чуваки на питоне выдают результат за пару дней и стоят дёшево.
2. Чуваки на Java что-то совсем нихуя нам не поставляют годный функционал, да и еще и стоят дорого.
Очевидное решение со стороны бизнеса - разогнать Java. ))))
Очевидное решение со стороны бизнеса - разогнать Java. ))))
Ну не знаю. Тут надо смотреть, приносят ли программисты,а точнее их продукт деньги?
Я сам когда-то работал программистом в компании, которая делала отчёты. Наш отдел писал ПО для автоматизации процессов в самой организации и за ее пределами. Много лет писали и дорабатывали. Потратили на это кучу денег. Многие программы были написаны, но никогда не применялись вообще. А специалисты этой компании так и продолжали делать отчёты вручную в Ворде, используя обычный калькулятор. Брали прошлые отчёты и в них часть информации меняли на новую. Как они говорили, им так привычнее. В итоге компания разорилась, причем как раз из-за вложений в IT разработки. Директора (несколько ооо было) стали Ипешниками и сами стали вручную делать такие отчёты. То есть, в этом случае компания просто выбрасывала на ветер деньги, которые зарабатывались специалистами, которые вручную делали отчёты. Конечно, в таком случае надо было как можно раньше закрыть наш отдел или оставить одного. А нас было человек 10 и все получали выше среднего по рынку.
Но в вашем случае у вашего продукта есть пользователи, в отличии от нашего. А значит, он продается. Пользователи ждут обновлений, значит продукт востребован, может и дальше приносить прибыль.
И да, писать какую то систему за 100500 мильенов вообще не нужно. Вот например берете Apache NiFi - бесплатную штуковину. Поднять и настроить на получение данных с практически любого источника, перекодирование в любой формат и сохранений в нужном результате - хоть в БД, хоть в xls файл - максимум неделя, при условии что вы видите это впервые. Для чела кто с ней работал - пару дней делов. Там вообще программирование не нужно, толковый админ вполне справится.
Что мешает производителю (судя по объемам не мелкому) сделать нормальную систему документооборота для своих клиентов?
Если клиент постоянный, с ним уже давно обменялись X.509 сертификатами, согласовали контракты и произвели разработку - то никаких проблем.
API, по которому клиенты смогут забирать нужное например сразу в 1с
Но это "нужное" в неструктурированном виде интереса не предстваляет. А структура у всех различна. Как следствие, каждый такой обмен по B2B шине - уже согласование контрактов и разработка.
Это как детализация звонков у сотового оператора. Для корпоративных клиентов выгодней заказывать её в xml, загружать в свою БД и обрабатывать там. Для пользователя, наоборот, удобней xls, потому что его проанализировать можно сразу.
json схема/xsd - не, не слышал. Ну это так, к слову, если вы вдруг не знаете что давно придуманы специальные форматы для автоматической трансформации данных.
Вообще, поставщик делает сервис, который предоставляет данные в нужной структуре и в нескольких форматах json, xml и в том числе и xls. Уж поверьте, когда у них есть база, то выкатить вам любой удобный формат - плевое дело. При том что есть APİ, по которому клиент самостоятельно это сделает - заберёт в удобном для него формате и дальше если необходимо преобразует как ему надо. В этом и заключается суть - поставщик предоставляет данные в оговорено формате. Клиент тоже видит этот формат и подстраивается под него. Благо то, что вся эта кухня с прайс-листа и, складским учётом и пр.бухгалтериец давно известна и выработать формат удобный для всех - не проблема. Даже больше скажу, есть уже готовые форматы обмена, которые не то что общепринятые, а даже утвержденные какой то там комиссией/центром - не помню точно название. Например та же 1с его активно использует.
Не надо делать трагедию на ровном месте. Проблема возникла не вчера и много чего уже придумано. Нужно просто делать, а не говорить что у нас лапки и мы не можем
json схема/xsd - не, не слышал
Это Ваши проблемы )))
Уж поверьте, когда у них есть база, то выкатить вам любой удобный формат - плевое дело.
Расскажите это, например, разработчикам АСОУП-3, у которых только через три месяца разработки сервис перестал уходить в нирвану уже от нескольких миллионов запросов в сутки. А с консистентностью данных до сих пор проблемы, которые еще с сентября прошлого года решить не могут. К тому же они упорно не желают переходить на protobuf, что заметно повышает нагрузку как на процессор и память, так и на сеть.
есть уже готовые форматы обмена
Есть готовые протоколы. Но, практически, нет готовых контрактов. Даже в прайс-листах кто в лес, кто по дрова. Посмотрите хотя бы на содержание драгметаллов. У кого-то это просто строка, которую надо еще отпарсить. У кого-то это разворачивается в pivot. И только у некоторых - через подчиненную таблицу с кодами из справочника, который интегрируется отдельно.
Только меппинг справочников разных поставщиков к единому целому с автоматическим дополнением, слиянием и разрешением конфликтов, обычно, требует несколько месяцев работы. Утвержденной глобальной НСИ - кот наплакал.
Ну и возвращаясь все же к теме. С какого перепугу Вы решили, что для разовых запросов кто-то будет поднимать B2B шину, вести соответствующую разработку и осуществлять её поддержку? Разовые запросы всегда будут, для разовых запросов формат электронной таблицы удобней, а значит ограничение в 20 тыс. строк становится неприемлемым.
Да это как раз не мои проблемы - я то это знаю и активно пользуюсь. :)
Так вот именно о том я и говорю - что бы не было "кто в лес кто по дрова" и нужно делать сервис, который будет предоставлять данные в удобном едином формате.
Ну вот вы и сами подвели базу: 20 тыс. неприемлемо? Ну так это ваши проблемы то получается. Не хотите делать хорошо - мучайтесь. :)
Для пользователей не придуманы. Это для интеграций есть REST, SOAP, gRPC и т.п. А пользователю удобней xls/ods, если требуется анализ данных.
Не всякий IT аналитик сможет по jsonb запросы строить, не то что пользователь.
Так о том и речь - поставщик предоставляет данные в том же json, а уже клиент на своей стороне преобразует данные в нужный формат. Уж поверьте на слово, перегнать json в xls - это десяток строк кода. Речь то идет как раз об автоматизации процесса. то что можно автоматизировать - должно быть автоматизированно. Вы наверное не поверите, но существуют и аналитические системы, которые прекрасно понимают всякие json и на выходе строят всякие графики и пр. Внезапно, но эти системы как раз для аналитиков. Если ваши аналитики не могут ничего кроме эксель... хреновые у вас аналитики. Или компания такая. Купите счеты и бухгалтерскую книгу - самое оно будет.
Так о том и речь - поставщик предоставляет данные в том же json, а уже клиент на своей стороне преобразует данные в нужный формат.
Берем любого ОПСОСа. Предположим, что детализацию он предоставляет только в JSON, в соответствии с Вашей рекомендацией. Как Вы думаете, как это отразится у него на клиентской базе?
Уж поверьте на слово, перегнать json в xls - это десяток строк кода.
Не верю, так сам не раз этим занимался. JSON не содержит данных по стилям, форматированию и типизации, но зато поддерживает массивы, иерархии и ссылки на внешние НСИ. Это принципиально разные форматы.
Если ваши аналитики не могут ничего кроме эксель... хреновые у вас аналитики.
Судя по Вашей лексике, у меня сомнения, что Вы сами даже такой запрос сможете написать: $.track ? (exists(@.segments[*] ? (@.HR > 130))).segments.size()
Похоже вы путает мягкое и теплое. json это формат обмена, он не предназначен для работы конечного пользователя с ним. Поставщик предоставляет вам эти данные, а вы уже делайте что вам нужно. Например прикручиваете WEB-морду, где уже данные их json будут консолидированы, посчитаны и проанализированы. Обычно разработчик API предоставит несколько вариантов форматов данных. Но если по какой то причине, данные только в json, то опять же - нет ни каких проблем. Берем Apache NiFi , за пару дней делаем DataFlow процесс, который сходи в сервис поставщика, заберет оттуда данные, преобразует их в xls и сохранит/отправит на emal. При этом не надо там быть программистом. Почитайте уже что это https://habr.com/ru/companies/rostelecom/articles/432166/
Верят в Бога, а технологии изучают. Прям вот глазками берут и читают документацию. Не знаю чем вы там занимались, но вот вам фрагмент кода (см скрин), который формирует xls с разукрашиванием и даже с условным форматированием. Если бы я этого не делал сам бесчетное количество раз, то и не говорил бы.
Понятие не имею о каких запросах вы говорите, мне как разработчику ближе такие:
SELECT `t`.*
FROM `user_fio` `t`
JOIN (
SELECT `user_fio`.`user_id`, MAX(`user_fio`.`date`) AS `date`
FROM `user_fio`
GROUP BY `user_fio`.`user_id`
) `user_fio`
ON `t`.`user_id`=`user_fio`.`user_id`
AND `t`.`date`=`user_fio`.`date`
WHERE `t`.`surname` REGEXP "^Первые_буквы_фамилии"
AND `t`.`name` REGEXP "^Первые_буквы_имени"
AND `t`.`patronymic` REGEXP "^Первые_буквы_отчества"
И да, у нас аналитики используют другие средства. А в экселе только секретари разве что таблицу отпусков составляют. Сдается мне что вы просто пытаетесь показать важность и нужность работы. Создание видимости сложности простых вещей.
json это формат обмена, он не предназначен для работы конечного пользователя с ним
Так это не я, это Вы предложили JSON для разовых запросов клиентом:
Так о том и речь - поставщик предоставляет данные в том же json, а уже клиент на своей стороне преобразует данные в нужный формат.
вот вам фрагмент кода
Это не пример, а позорище. Попробуйте ж/д накладную так раскрутить, которая ссылается на два-три десятка справочников и имеет иерархическую вложенность в пять уровней.
А это еще не сложный документ. Та же ГУ-12 куда поинтересней.
Понятие не имею о каких запросах вы говорите
Сами же предложили JSON. А при этом языка jsonpath не знаете.
WHERE `t`.`surname` REGEXP "^Первые_буквы_фамилии"
Вы действительно думаете, что на Пикабу все тупые и не увидят, как Вы загоняете запрос в fullscan, даже если есть индекс по surname? Или Вы не разработчик и даже не смотрели, что показывает EXPLAIN?
Именно так - запросы к API, в ответ json - и трансформируйте во что угодно. Разовый запрос - это когда один раз запросил и больше не вспоминаешь о нем никогда. Но если этот запрос делается не раз (с ваших же слов) - это уже нихуя_ниразу_неразовый_запрос. А значит подлежит автоматизации. Вам уже тут несколько человек помимо меня сказали - проще загнать в БД, отфильровать и выдать готовый результат. Скрипт пишется за пару часов не напрягаясь. И да, скрипту проще будет именно json. Но конечно вам надо показать начальству что вы охуенный спец и без вас тут ни как.
Этот фрагмент кода - пример работы с библиотекой, если вдруг не заметил комментарии. Не ваши ли слова что невозможно сгенерировать xls с форматированием? Так вот этот пример как раз про это - возможно и очень даже легко. Если вы чего то не знаете, то это не значит что это не возможно. А иерархия любой вложенности обходится простейшей рекусией даже. В чем тут проблема вообще не понимаю. Уж поверь всякие приходилось разбирать и конвертить.
И да, продолжаю настаивать что надо json использовать (как вариант). А вот jsonpath использовать для разбора - только если на наркоте сидишь. Потому для вас иерархия - это охренеть как сложно. Алгоритмы почитай, обход деревьев там, поиск в глубину опять же. Может перестанет быть проблемой.
Запрос SQL - это просто первый попавший под руку пример. Строка "^Первые_буквы_фамилии" - не смутила? Вообще то тут должно быть выражение. Или вы думали что я вот прям ломанусь вам реальные запросы показывать Я конечно могу, но смысл то в чем? Доказывать что план запроса хорош? Да он даже если хреновый будет, все равно jsonpath уделает по эффективности.
Ну если уж так хочется посмотреть как взрослые дяди работают с json - ок покажу реальные запросы. И обратите внимание - там 860 млн - это только одна коллекция, а есть и побольше. Не какие то жалкие 20к. Без всяких jsonpath на любой уровень. И в массив у объекта могу заглянуть при надобности.
Все ваши придумки - не более чем отговорки из-за неспособности решить нормально задачу. Кто может делать - делает, кто не может делать - ищет причину.
Простите, но мне стажёров и на работе хватает. Обучать Вас тут не стану. Просто укажу, что SQL Вам надо ещё учить и учить. Без jsonpath лишаете себя весьма эффективного jsonb. Хардкодить трансформации, вместо выноса их в описание схемы или хотя бы плагина - уровень джуна. Использовать JSON для высоконагруженных API, а не тот же protobuf - непозволительная роскошь.
Да уж куда уж мне до вас то :) Ну да, я вижу использовать json в posgrese - это прям верх эффективности, ага. Трактористам на своем хуторе рассказывайте. Как и про эксель для аналитики :) А я уж как нибудь обойдусь вещами изначально предназначенными для этого. Не знаю где вы там и чего хардкодите, но мои ETL прекрасно перелапачивают миллионы json. При том заметьте, совсем без jsonb - его просто не существует в монге. И о чудо - прекрасно понимает объекты для фильтрации, пайплайны и агрегации. Но дело тут сугубо ваше, можете хоть дрочить в присядку.
protobuf? А может все таки (g)RPC? в понятиях разберитесь, прежде чем стажерам мозги засерать. О каких вы там высоконагруженных сервисах говорите? Это о 20к строках что ли? Да в той же монге рекомендуемый батч на сохранение от 10к. Такие объемы даже json без сжатия схавает и не поморщится. Но это вы уже тут притягиваете за уши. Изначально речь шла о любом удобном формате, ровно как и протоколе. И json тут выступал только в качестве примера. Если сказать по делу нечего, то не надо на частности переключастся. Всегда проще обвинить других в своих проблемах, чем признать собственную неспособность решить задачу. Если уж обвиняете МойОфис, то хотя бы в сравнение привели альтернатив на вроде LibreOffice или WPS Office.
