А коли допилите до нормального стану, стане схожим на query builder в Access або Power Query в excel.

Все Query Builder‘ы так или иначе работают с join и group-by, которые нормальный пользователь (бухгалтер) не понимает какой бы UI их не прикрывал. В Data Commandr принципиально нет никакого Query Builder‘а — пользователь напрямую пишет формулы как операции на колонках. Но какие-то визарды для типичных операций конечно не помешают (в будущем), но все равно они будут генерировать определения колонок.

Смисл ?

Смысл сделать работу с данными доступной любому непродвинутому пользователю далекому от IT. То, что раньше делали эксперты на SQL, должен делать бухгалтер.

Можно ли эффективно «группировать и комбинировать» данные из нескольких источников, не понимая базовых принципов работы с множествами (фиг с ней с алгеброй, понимания на пальцах хотя-бы)? А можно ли понимая эти принципы споткнуться об SQL?

Все суть DC в том, что он не требует понимания работы со множествами поскольку множеств и операций со множествами там нет — это другая модель данных.

Почти все широко используемые подходы к преобразованию данных (включая языки запросов) основаны не операциях со множествами. Чтобы вывести новые данные, надо взять существующие таблицы и применить к ним операцию. В Data Commandr данные выводятся по другому. Чтобы вывести новые данные в DC, надо взять существующие колонки и применить к ним операции. Формально у нас получается граф операций над колонками (а не таблицами). В DC нет никаких join или group-by, а есть множество колонок в разных таблицах, которые имеют свои определения в виде формул. Пользователь просто добавляет новые колонки и дает им определения. Это как в Эксель, но только вместо ячеек формулы имеют колонки.

Что может делать Data Commandr, чего не может делать Excel?

Если на базовом уровне без приспособ и расширений, то Эксель это работа с ячейками с двумя координатами. Там нет таблиц как они понимаются в реляционных базах данных, да и просто по жизни, скажем, зарплатная ведомость. Это удобно расширенный калькулятор, а для обработки традиционных таблиц (как множество записей) это не предназначено. Поэтому формально их вообще нельзя сравнивать.

Попробуйте привести конкретный пример, когда «тулы либо не потянут».

1) Связывание таблиц (join). 2) Агрегирование (group-by).

В результате обычно приходим к жесткому компромиссу: либо это делает все, но обычные пользотели не понимают и не используют (получает тул для технарей), либо пользователи довольны, но работа сводится к ограниченному числу простых паттернов. Примеры «тул не потянет» легче всего найти в программах для визуалльной аналитики (коих море, но можно взять Qlikview или Tableau), в которые данные должны быть уже загружены в «правильной» форме, поскольку внутренние возможности очень ограниченны.

Что касается знаний SQL. Для работы в Вашей системой ее изучать потребуется? Не будет-ли это изучение сложнее, чем изучения нескольких базовых операций SQL? Просто не думаю, что «интуитивно понятными» действиями в действительности можно реализовать «сложные преобразования и вычисления».

Изучать систему конечно потребуется, но примерно на уровне Excel (это конечно гипотеза, которую надо проверять). Т.е. если человек может освноить Excel, то значит сможет изучить Data Commandr (DC). Чтобы сделать что-то в Эксель, надо понять, как писать формулы, например, A1=B3*C5. Чтобы сделать что-то в DC, надо понять, что колонка это формула от других колонок, Amount=Price*Quantity.

Все проблема в формулах, которые должны собирать данные из разных таблиц. Собственно, специфика (USP) этой системы в том, что это можно сделать, причем в довольно общем виде. Пока мне не знаком подход, где бы это было возможно (кроме довольно кривых попыток в Microsoft DAX). DC основан на операциях с колонками, тогда как большинство других (мне известных) подходов и систем основаны на операциях с таблицами. Извествно (по Эксель), что написание формул для пользователей гораздо проще, чем операции с таблицами (join, group-by и т.п.)

Посмотрите, что в этом плане можно сделать том-же Access’e. А поскольку интеграция Access <->Excell весьма тесная, то подумайте, как Вы будете конкурировать с этой парой.

Для обычного пользователя (бухгалтера) Access слишком сложный, а Excel простой но ограниченный (он не для работы с таблицами). Гораздо ближе по духу Microsoft Power BI со своим языком DAX, где они тоже попытались обобщить формулы Excel на случай таблиц. У них не очень получилось, но DAX это одно из лучших что я знаю.

На самом деле DC в нынешнем виде пересекается, например, с airtable.com — самое быстрорастущее SaaS приложение за 2016.

Да, тоже заметил. Процесс бежит, но не отвечает. Не ясно, в чем проблема, не было еще такого. Пересадил на nginx. Надеюсь не подведет.

Запустил заново. Все работает.
Apache сервер умер из-за этого:
AH00326: Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Похоже Apache все-таки умер под нагрузкой (REST сервер на Tomcat живой). За ~5 часов он пассивно отдал ~400MB через ~200 запросов. Даже если это много, зачем умирать? Через час другой починю. Наверное лучше поставить нормальный nginx, а то к Apache httpd нежный какой-то. Всем спасибо за клики и пардон за сбой.

Перегрузил страницу пару раз для проверки. Где-то 2-3 секунды на загрузку страницы (сервер в штатах, браузер в Германии). Это я не в плане оправдания, а просто проверить, что приложение все еще живое. Попробуйте заново перегрузить. (Не знаю, но может старый коннект уже мертвый.) Если не идет, надо будет подумать, как уменьшить приложение. Говорят, в Angular можно как-то по частям загружать, но я не знаю как. Может еще проблема с куки быть, но он должен сказать, если что не так.

Видимо N человек одновременно кликнули. Это VM на Azure Cloud, 2 Cores, 8 GB. Не знаю, много это или мало, но видимо мало, если он начал отказывать. А может Apache надо как-то лучше сконфигурировать (он раздает большие Angular файлы).

Хм. Только что открыл в браузере — грузится и работает.
А что говорит? Начинает грузиться и не заканчивает? Или вообще не коннектится? Или обрывается?