Хоча з іншого боку
" Як бути з переказом з-за кордону на валютний рахунок? Чи є ліміти, обмеження?

Оскільки йдеться про валютний рахунок наявного та уже ідентифікованого клієнта банку, жодних лімітів на зарахування коштів на рахунок законодавством не встановлено."
Але я б на це не сподівався

«Ні, банк не повинен запитувати про походження грошей, якщо сума є незначною. Походження коштів банки мають право лише у випадку значних операцій — на суму понад 400 тисяч гривень. До речі, раніше цей поріг складав 150 тисяч гривень — тобто, відбулося значне спрощення.

Але треба враховувати важливий момент. Внутрішні правила банку можуть бути більш жорсткими, аніж вимоги закону. Деякі банки і раніше могли питати про походження сум 50-100 тис. гривень, а зараз і поготів. Закон не забороняє банкам бути більш прискіпливими до клієнтів.»
Плюс можуть бути додаткові обмеження для різних типів рахунків, треба консультуватись з конкретним банком.

Нет смысла хранить джейсон в базе без необходимости. Это в перспективе делает рост размера базы линейным в зависимости от роста пользователей и существенно уменьшает требования к ресурсам. Если возвращать джейсон из функции, то можно примерно оценить объем данных, передаваемых из базы, при желании можно возвращать данные в каком-то условном компактном формате и формировать джейсон на клиенте, что опять же уменьшит размер трафика между базой и приложением.

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

create or replace function get_userinfo
			( user_id bigint
			)
returns JSON as $$
select json_build_object (<your json format>) 
from (
<here your join user table with other tables having details>
) t;
$$ language sql;

А для тих щасливчиків (буржуїв), які заплатили за підтримку, є Doc ID 1416063.1 на support.oracle.com
Там багато різних опцій насправді по лікуванню.

найбільш цікавий рецепт на тему відновлення після цієї помилки я бачив тут:
forum.hostmachine.net/viewtopic.php?p=715
Але це для панів, які мають час і натхнення, або не мають іншого вибору, тобто бекапу)

Хм, я думал что такие истории можно услышать от развеселых жителей Швейцарии, а оно вона как...)

ну я особисто не пам’ятаю 27к брутто на умове о праце, але можливо що я відстав від життя. Для B2B це має бути рейт десь 170, що не є чимось дуже захмарним, і звісно може бути навіть вищий рейт. Але знову ж таки, отримувати 27к або 30-40к не на B2B — можливо що і таке є, але цікаво було б побачити.

А можете показати приклад такої позиції на 27K брутто?

ЄСВ — це обов’язок роботодавця, це завжди так

так в чому «зламаність»?)

моделі з ФОПами — кришка

це теж гарний підсумок)

Якщо підсумувати, то Борняков відверто брехав про відміну податкових норм із 3933, або не знав.
Законопроект 5376 фіксує ставку 22% ЄСВ для «небілих» працівників, тобто тих що не є оформленими в штат, і додає ще одну морковку для компаній, які потенційно планують стати резидентами. Тобто до зменшеної ставки податку на прибуток додається зменшений розмір нарахувань у разі оформлення працівника в штат.

Тю, все вони прекрасно розібрались)
При цьому явно вони врахували критику за те, що «гіг-контрактори» не мають ніяких прав, тепер для «традиційного оформлення» — всі права на місці, а для інших форм співробітництва — трохи «вищі» податки)

так в 3933 було те саме, тут тільки додалось оце (наскільки я розумію):
" а) на суму нарахованої кожній застрахованій особі заробітної плати за видами виплат, які включають основну та додаткову заробітну плату, інші заохочувальні та компенсаційні виплати, у тому числі в натуральній формі, що визначаються відповідно до Закону України «Про оплату праці», у розмірі мінімального страхового внеску;"
Тобто вони теж згодні з тим, що гіг-контракт — то якась некоректна норма, і вирішили ще одну морковку вивісити, цого разу, у вигляді зменшених нарахувань)

Все одно ви своїми ж дописами довели що SQL зовсім не читабельний стає при вирішенні цих досить таки типових (і здавалось би тривіальних) задач. Що і треба було довести.

)) На тому і розійдемось)
Мій досвід говорить мені що будь-який аналітик надасть перевагу SQL ніж чомусь подібному до Logica.
Тим більше що як ці «досить типові і тривіальні задачі» вирішуються в Logica, я так і не побачив, на жаль)

Це коли таймзона береться per connection? До дупи це — різні юзери будуть реюзати різні коннекшни до бази, коннекшни практично завжди pool-аються і реюзаються.

ну не можна ж так фейспалмити) зміна локальної таймзони — це один стейтмент, який буде виконуватись на рівні сесії після взяття з пулу конекшена.

А в MySQL є такий? :-)

Я не знаю як в MySQL, але півхвилини гугління дають це:
«Have the client specify its time zone when it connects to the server by setting the time_zone system variable.»
«MySQL interprets TIMESTAMP values with respect to each client’s time zone. When a client inserts a TIMESTAMP value, the server converts it from the time zone associated with the client connection to UTC and stores the UTC value. (Internally, the server stores a TIMESTAMP value as the number of seconds since 1970-01-01 00:00:00 UTC.) When the client retrieves a TIMESTAMP value, the server performs the reverse operation to convert the UTC value back to the client connection time zone.»
www.oreilly.com/...​d/059652708X/ch06s04.html

Це не verbose? Це clear and concise?

«date_trunc(’hour’, ship_ts) — (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 12) * interval ’1 hour’»

Я зараз процитую:
«Ви не зрозуміли нічого :facepalm:»
Це тільки у випадку якщо змінюється «грануляція» для групувань. Якщо для кожного інтервалу потрібне групування по днях, то ясно що нічого з цього не потрібно, там буде тільки date_trunc(’day’, ship_ts). Тобто весь запит буде декілька рядків, включаючи grouping sets.
Цей же запит в Logica буде в кілька разів довшим, я вже не кажу про те що його неможливо буде зрозуміти. А якщо додати можливість різної грануляції інтервала групування, то таке мабуть неможливо написати в Logica в принципі.
Але рівень Ваших знань в SQL вже зрозумілий, дякую)

В кожного користувача буде СВОЯ ТАЙМЗОНА. Вона НЕ ЗБІГАЄТЬСЯ з якоюсь ОДНОЮ таймзоною серверу.

ОБОЖЕ, у кожного користувача своя таймзона, який жах!) Відкрийте для себе конвертацію у клієнтську таймзону, яка буде робитись по-різному в різних СУБД звісно.
Ще раз, таймстампи з таймзоною вирішують будь-які проблеми, в тому числі і конвертацію (тим більше, що зберігається все в UTC все одно в разі використання timestamptz, наприклад). Конвертація при читанні у випадку Postgre буде робитись в запиті, в процессі вставок така конвертація проходить автоматично.
Або в тому ж самому Oracle є такий тип — TIMESTAMP WITH LOCAL TIME ZONE, спеціально для таких випадків, і тут взагалі навіть не потрібно нічого конвертити, все конвертиться автоматично і при додаванні значень, і при читанні.
Те що Ви про це ні сном ні духом, зовсім не означає що цього немає.

Типова задача — bar chart (стовпчикова діаграма) де кожен стовпчик ще всередині розбитий на підгрупи

ОБОЖЕ, яка складна задача!
Відкрийте для себе grouping sets може?)
Так я побачу хоч якийсь приклад з Logica?

це друга хєрня, навіщо вона в контексті тієї квері про mentions, мені не дуже зрозуміло.

)) да будь-яка задача підійде, яка різниця?) що таке «розбивка по запчастинам»?) Таймзона вирішується типом timestamp with timezone — ваш кеп)
для різних періодів буде щось подібне — в даному випадку це кверя, яка може бути упакована в процедуру з параметрами, для «фіксованих» і різних періодів групування (в прикладі 2 години, 12 годин і 1 день), якщо потрібні конкретні інтервали, можна передавати окремі дати початку і кінця, це ще простіше.

select      
          CASE
           WHEN in_group_interval = '1W'
           THEN
            date_trunc('hour', ship_ts) - (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 2) * interval '1 hour'
           WHEN in_group_interval = '1M'
           THEN
            date_trunc('hour', ship_ts) - (CAST(EXTRACT(HOUR FROM ship_ts) AS integer) % 12) * interval '1 hour'
           ELSE
            date_trunc('day', ship_ts)
         end as group_ts
    from shipment
    where ship_ts > current_timestamp -
       CASE
          WHEN in_group_interval = '1W'  THEN interval '1 week'
          WHEN in_group_interval = '1M'  THEN interval '1 month'
          WHEN in_group_interval = '1Q'  THEN interval '3 month'
          WHEN in_group_interval = '1Y'  THEN interval '1 year'
        end