На самокате, велосипеде оттолкнулся ногой, есть запас инерции, чтоб поймать равновесие и проехать несколько метров без педалей.
На моноколесе такого запаса инерции нет, оттолкнулся ногой, встал ею на подножку, надо сразу себя перебороть, ногами (телом) продавить педали (газовать).
Стоять без движения на моноколесе, как на двухколесном гироскуторе, тоже не получится.

… навыки удержания баланса полученные на любом виде техники вроде самоката, велосипеда, роликов и прочих коньков, никак не помогают...

Главное отличие моноколеса — само оно не катится. Обучение через «оттолкнулся-поехал», как с самокатом, велосипедом, и т.п. здесь не работают, они в первую очередь и мешают.

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

формульные модели вряд ли будут доминировать в экономике и её отражении в IT. Скорее будут господствовать алгоритмические модели.

… интересно (не хватает в статье), как физики смотрят на теорию игр, в том числе, в экономике?

Почитал документацию, для себя определил PipelineDB, как механизм агрегирующих счетчиков в режиме реального времени. Счетчик от потока отключил, агрегированные данные потерял.
Идея интересная, но не для случая уже хранимых данных. Удобно для данных, которые только планируется сохранять, с учетом, что счетчики должны быть включены заранее.

Мне очень понравился первый абзац:

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

Что если у меня уже есть Postgres DB со своими таблицами, к которым требуется писать множество агрегатных запросов. Я так понимаю, чтобы использовать PipelineDB, я должен переместить таблицы в PipelineDB или написать некие правила для отправки данных из своих таблиц в PipelineDB? — этих правил в статье я не увидел.

А где в статье связь между запросом

SELECT hour(datetime), somename, count(*), sum(somemetric)
from table
where datetime > :monthAgo
group by 1, 2
order by 1 desc, 2

и стримом

CREATE FOREIGN TABLE flow_stream (
    dtmsk timestamp without time zone,
    action text,
    duration smallint
) SERVER pipelinedb;

Я так понимаю, в «table» нужно триггер или правило добавлять, чтобы заливать данные в «flow_stream»?

… глубокое знание экономистом специфики бизнеса своей компании и понимание логики бухгалтерского учета на уровне главной книги, позволяющей классифицировать любую хозяйственную операцию в виде бухгалтерской проводки. И именно на такого специалиста рассчитана система JetCalc.

Качество работы этих мифических специалистов меня очень сильно и беспокоит.

Более того, концепция бухгалтерской проводки (двойной записи) в JetCalc расширена и названа бизнес-транзакция (коротко «бизтран»)

Ткните меня, пожалуйста, где можно пощупать ваши «бизтран». В описании системы слишком кратко и операции между двумя юридическими лицами пока не интересуют.

Интересует система с возможностью формирования описанных вами отчетов из данных в виде двойной записи (проводок) с индивидуальными наборами аналитики по каждому счету. Я понимаю, что технически это реализуемо в JetCalc. Интересует, существуют ли инструменты удобной работы пользователя с двойной записью, когда проводок >1млн. большая часть будет загружаться из учетной системы, но пользователи должны иметь удобные инструменты корректировки и анализа данных, также важен контроль ввода аналитических признаков по 60 — Контрагенты, договоры, по 10 Номенклатура, по 20 — заказы и т.д…

Из Начало работы в JetCalc. Глава 6. Расчетная система

1...., в системе JetCalc используются ячейки вида $f105215@On?, где $f105215 — код строки (строка 215 формы f105), @On — код колонки (остаток на начало),? — завершающий символ.

2. В системе JetCalc каждая ячейка имеет шесть измерений — строка, колонка, год, период, объект учета, валюта — поэтому полный синтаксис ссылки на ячейку, представленной в предыдущем пункте, будет выглядеть следующим образом: $f105215@On.Y2017.P11#210[RUB]?, где .Y2017 — 2017 год, .P11 — период 11 (январь), #210 — предприятие с кодом 210, RUB — код валюты рубль.

— ну, никак не альтернатива для простого экономиста, освоившего =СУММ(A1;A76). Как технологический конкурент для Oracle Hyperion Planning или решениям на 1С вполне допускаю.

Проблема не в изменении модели, а в скорости такого изменения. Если руководителю нужна информация завтра, а модель может быть изменена послезавтра, то такое изменение никому не нужно — решение будет принято на основе старой модели с некоторыми поправками в голове руководителя.

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

И решение этой проблеме давно уже придумали. В экономике закон сохранения стоимости такой же, как в физике закон сохранения энергии: если где-то что-то убавилось, значит куда-то в таком же объеме прибавилось. Правда экономисты от этого бухгалтерского закона, как от огня бегают, поэтому и системы бюджетирования высоко взлетев, часто больно падают.

Мой совет. Присмотритесь к планированию движения стоимости в виде двойной записи — как в бухгалтерии факт учитывается: Дебет-Кредит-Сумма. Чтоб в модели с самого начала баланс был заложен, когда расходы с доходами сходятся. Такого ваши конкуренты пока почему-то не предлагают.

array_to_string(array_agg(any_val),';') можно сократить до string_agg(any_val,';')

А еще, планировщик с большей вероятностью использует индекс по t2_id в

SELECT * FROM table1 WHERE t2_id=ANY((SELECT array_agg(id) FROM table2)::integer[])

чем в

SELECT * FROM table1 WHERE t2_id IN (SELECT id FROM table2)

в зависимости от объема записей в table2

фнс любит ходить по этим спорным моментам

Профессиональный бухгалтер тоже пойдет в арбитраж, если не согласен с фнс.
А вот программисту желательно иметь основания не появляться там по этим спорным вопросам.

Другой пример с положительной судебной практикой для налогоплательщика
Показывает лишь то, что вопрос не технический, а экономический и юридический. Программисту остается только затребовать четкое ТЗ, как считать суммы.

PS: Бухгалтерский учет часто не понять логически. Бывают законы, которые противоречат друг другу, или наоборот, не раскрывают важные моменты, как с округлениями. В таком случае судьба предприятия будет зависеть от позиции бухгалтера, его опыта, умения вести разговор с инспекцией. Поэтому как он скажет...(2+2=5 ;-)

… Часто бывает, что общий итог <> итог по колонке сумм… И тут возникает вопрос, как от этого избавиться?

Не стоит технарю решать проблему экономиста/бухгалтера?

Опишите прямой алгоритм расчета (когда сумма по ИТОГО не сходится с ПРОИЗВЕДЕНИЕМ) или обратный (когда сумма по ИТОГО с ПРОИЗВЕДЕНИЕМ сходится, но в последней позиции копеечка подправлена). Подпишите порядок расчета у Главного экономиста(бухгалтера). И не ломаете себе голову.

… налоговая это нормально хавает.

… в форму ввода с настроенным срезом из куба… основные цифры вводят руками начальники подразделений и финансисты...

Вот это и странно.
OLAP задумывался как агрегатор больших массивов данных в разрезе разных уровней аналитики (измерений). Когда данные собираются автоматически, не возникает никаких вопросов об их согласованности.

Но для систем бюджетирования видимо посчитали, что в Куб целесообразнее вводить данные вручную. И тут возникает проблема, пользователи часто ошибаются, финансовый баланс в данных нарушается, суммы расходов не соответствуют суммам доходов.

Надо понимать, что в бюджетировании заполняются десятки отчетных форм с сотнями реквизитов. Функция проверки сходимости финансового баланса требуется для каждого реквизита. И далеко не факт, что разработчик бюджетной модели сам не накосячит где-то среди формул для сотен реквизитов.

Так не проще ли предложить пользователям функционал для ввода финансовых данных в форме двойной записи (проводки) с заведомо сходимым балансом. А в Куб данные загружать автоматически, как и было задумано родоначальниками OLAP?

… соблюдения разумного баланса между математикой, трудоемкостью ввода информации и наглядностью отчетов...

А ввод данных ручками в бюджетный OLAP считается нормой?

Статья про plpython-ориентированный механизм аутентификации, а не «разграничение доступа». Ваш GD.get('user_id') можно и RLS засунуть. Я не говорю о достоинствах и недостатках предложенного метода. Я лишь про название и содержание статьи.

догнать рейсовый автобус

За положением рейсовых автобусов в крупных городах уже можно наблюдать в режиме реального времени. Но это хлеще гонок маршруточников. Особенно, когда пассажир через новомодный сервис подглядывает за рейсовым автобусом и подгоняет водителя.

Далее: кажется, что в городах с большим количеством пробок возникают ситуации, когда часть маршрута удобнее проехать на общественном транспорте или даже пройти пешком, а затем снова пересесть в такси.

В недалеком будущем, водитель пассажиру: «Уважаемый, впереди пробка 1000м. Но наша замечательная автоматизированная система о Вас уже позаботилась, в конце пробки Вас ожидает другой автомобиль. Покиньте пожалуйста такси, перейдите к другому...»

Пока нам проще подождать, может кто-то сделает это.

Тут наверное стоит задать обоюдный вопрос к разработчикам PostgreSQL.

1. Существует ли реальная задача под которую создавался RLS, или статистика с практикой применения и администрирования?
2. Реализованный RLS действительно неудобен и не отвечает реальным потребностям в прикладных задачах, какие есть планы по доработке?

В процедуре постгрес можно любую ересь написать. А в непродуманном оракле при сохранении процедуры проверяется и наличие и правильность типов всех ссылаемых объектов.

1:1 ;-)

Именно так (генерация предикатов в рантайм) и сделано у нас в версии для оракла. И именно по указанным причинам пришлось отказаться от поддержки в версии для постгреса.

Если нужен предикат в рантайме для конкретного пользователя, могу посоветовать решение из собственного опыта. В постгресе есть CREATE TEMP VIEW… Перед INSERT, UPDATE, DELETE или SELECT генерите временное представление с добавленным предикатом и работайте с ним, при этом сама таблица может быть недоступна пользователю, а во временном представлении будут доступны только нужные записи.

3… В оракле полиси это функция, которая возвращает предикат, в пг это сам предикат.

Постгрес не позволяет вставить политику, если в предикате ошибка, к примеру указано несуществующее имя поля. В оракле RLS (на зуб) не пробовал, но так понимаю он проверку не делает, а ошибки, если есть, выдает уже после обращения к данным.

Такими мелочами постгрес выглядит на голову продуманней оракла. Этим же он уступает конкуренту в скорости развития функционала.

Вообще интересно посмотреть живой проект, в котором RLS руками пишется. Я RLS рассматриваю тока как сгенерированный из какой-нибудь вспомогательной таблички.