Comments 19
"Облегчение работуы"? И как, получается?
Извините, тут бесполезно по одной ошибке вам в личку таскать, вы бы свой текст перед публикацией перечитали хоть раз.
насышенным и функциональным интерфесом
А может изучить функционал Excel? И как в нем делать интерфейсы?
Каким образом вот это вот облегчит визуализацию 255 колонок и 65000 строк?
У Excel такой багаж наработок в плане анализа.
А уж в плане получения данных из гетерогенных источников…
Хорош уже заниматься велосипедостроением!
У меня, как у человека, который в этом "велосипеде" делал почти всё от колёс до руля есть ответы на ваши вопросы (надеюсь):
- А как правильно делать интерфейсы в Excel так, чтобы можно было показать пользователю конкретную страницу PDF файла из которого изначально был получен показатель, содержащийся в текущей ячейке? Неужели на связке VBA/MS Forms что-то писать в 2020 году? Может TaskPane со встроенным браузером? Или внешний процесс для отображения PDF файлов… Ну так у нас он есть — браузер называется. Если есть идеи как это сделать лучше/правильней — я с удовольствием выслушаю.
- Это решение никаким образом визуализацию не облегчит, потому что оно не для этого предназначенно. Наверное, тут проблема в том, что изначальная задача не очень понятно описана. Она не в том, чтобы получить табличные данные из базы и отобразить их в виде отчёта, она о том, чтобы из данные из разных неструктурированных внешних источников (отсканированные PDF отчёты) подготовить к загрузке в базу и дальнейшему анализу другими средствами.
Так что я двумя руками за существующие решения, но иногда приходится и велосипеды собирать из подручных материалов :)
Внешние источники данных вас спасут. Нет необходимости в этом зоопарке.
- Доступ к данным должен быть ограничен. Это должно решаться через централизованное управление правами. А это AD. И если взять за основу оперирование данными через внешние источники, эта задача бы решалась на уровне, например, MS SQL.
- Excel можно рассматривать как формат входящих данных и как движок для отчетов. Но не как БД для построения других отчетов. Теоретически это возможно. Практически, это ад кромешный для сисадминов и поддержки. Потому, что за формулами и связями стоят конкретные люди не ограниченные своей фантазией. Поддержание консистентности такой системы невозможно. Т.е. совсем. Это высокий операционный риск компании. В любой момент времени она может потерять ценные данные. И просто так из бэкапа их не восстановить. Потому, что многие из документов становятся «критическими» и актуализируются в реальном времени.
- Нужно разделять шаблон отчета и отчет. Управление шаблонами необходимо организовать через системы управления версиями. Частные отчеты необходимо фиксировать «как есть». Вне зависимости от изменяющегося шаблона. В противном случае, когда задача будет — «а соберите мне данные за последние 3 года» — это будет очередной ад.
Эта задача решается практически во всех финансовых учреждениях. Поищите релевантный опыт там. Это позволит избежать много «боли».
P.S. Вообще, я два раза перечитал статью и оба раза не совсем понял целевую задачу.
- Разграничение доступа конечно же есть. У нас реализована ролевая модель и существует «подсистема» управления правами. В статье я этого не касался, т.к. предмет был немного другой.
- В некотором смысле так и есть — с помощью этого инструмента пользователи создают и поддерживают свои модели привычным им способом. Вопросы версионности моделей мы не решаем (это не задача нашего инструмента). Версионность и контроль целостности самих данных, которые они загружают реализуется в нашей системе, но это таже несколько выходит за рамки статьи.
- Хранение готовых моделей и их дальнейшее использование не является областью применения нашей системы. Клиенты реализуют их по-разному. Некоторые могут хранить, например Excel-файлы в Sharepoint, где есть какое-никакое управление версиями. А для некоторых эта модель промежуточная, как вы упоминали — способ получения входных данных для других аналитических инструментов. И то что они сделали при помощи нашей системы, они выгружают куда-то еще.
Наверное, со стороны решаемая задача, для которой пришлось все это сделать, выглядит несколько непонятной. Но у нас взгляд замылен, мы в ней давно варимся :) Задача достаточно «отраслевая» и связана с повышением удобства переноса числовых данных из неструктурированых документов с сохранением привязки к источнику. Т.е. надо:
- быстро перенести данные в Excel
- иметь возможность увидеть число из ячейки в исходном документе (например, финасовом отчете)
- прeдоставить некоторые инструменты по работе с данными в виде функций Excel
А мы пошли обратным путем (https://m.habr.com/ru/company/arcadia/blog/498032/) и позволили пользователям продолжать работу в экселе по редактированию данных и настройке бизнес рассчетов. А вот визуализацию, анализ данных, сложные рассчеты оптимизировали на бекэнде и выдавали в более удобном виде для клиента, которому интересен лишь результат и красивая картинка.
1. Немного, но ощутимо подтормаживают.
2. Выглядят неряшливо (когда работаешь с таблицами по 5-6 часов в день такие вещи начинают бесить).
3. Во многих случаях их просто не принимает заказчик/целевой потребитель. Скажем, в требованиях банка к финмодели может прямо в первой строчке быть написано: «Модель представляется в виде файла Microsoft Excel версии не ниже ___».
Ну и вообще, Эксель это «наше все», устоявшийся отраслевой стандарт. Я сейчас начинаю очередной заказ, который прямо просится в Jupyter Notebook, но вместо этого делаю в Экселе, просто потому, что никто в команде кроме меня не пользуется ничем другим.
Может банально нельзя, просто интернет не положен?
1. Клиентам в основном нужно работать с Excel.
2. Для некоторых клиентов решение должно работать в сети, изолированной от Интернета или с сильно ограниченным доступом в Интренет.
3. Как уже упоминали тут в комментах, на больших таблицах Google-таблицы тормозят сильнее, чем Excel.
4. Возможностей по подключению к внешним источникам и загрузки данных в Google-таблицы меньше, чем предоставляет Microsoft.
Там возможностей хватает, но сильно проще разрабатывать и обновлять аддины.
Мы ерепробовали разные варианты решения этой задачи: и «чистый» RTD, и JS API. Но результат, удобный для пользователя предстказуемо работающий без сайд-эффектов, связанных с особенностями выполенения кода в Excel, у нас получился именно в том виде, который описан в статье.
Я всё собираюсь написать статью, которая расскажет про трудный путь к текущему решению через асинхронные UDF (которые оказались "иногда синхронными", причём в внезапно) к связке RTD + SignalR. Про некоторые неприятные сюрпризы от ExcelDNA и почему иногда мне хочется написать свою версию этой библиотеки (конечно с преферансом и институтками), а не использовать то, что есть. Ну а про то, что COM Interop в .NET вообще и в Excel в частности — это бесконечный источник боли, наверное, только ленивый не писал ещё :)
Как скрестить Excel c интерактивным веб-приложением