Артем Черепахин

Я бы попробовал как-нибудь вот так:

select *
  from clients c
 where exists (
 select null
          from (select abs(principal - lag(principal) over(partition by client_id order by report_date)) diff 
                  from principals p
                 where p.client_id = c.client_id
                 )
         where diff < c.payment_need
            and diff is not null)

Ключевое в этом запросе lag и exists. Exists должен искать до первого найденного несоответствия, что в среднем ускоряет выборку, а lag -значение по прошлому месяцу.

select t1. *, ntile(N) over (order by dbms_random.random) nbatch  from t1

А дальше выбираете нужные части nbatch.
ntile в Oracle используется для построения гистограмм, поэтому +/- должен работать быстро.

Здравствуйте. В части запроса over(... должны быть либо over(), либо over (partition by...), либо over( order by...).
У вас получился over ( "значение из group_level.partition_column;
")... так не получится- синтаксис аналитических функций другой:
https://docs.oracle.com/cd/B19306_01/server.102/b1...

Тут зависит от конкретной БД. В теге вопроса указано sql server, поэтому информацию по вашему вопросу можете почерпнуть https://docs.microsoft.com/ru-ru/sql/relational-da...

Плохо ищите наверное.
Я бы вам посоветовал почитать Т. Кайта, Д. Куна isbn= 978-5-907114-89-0, если у вас есть опыт работы с этой БД, хотя мне кажется и без опыта можно разобраться, тем более она на русском. Как прочитаете и поймете хотя бы до главы о типах данных, к этому времени у вас должен быть очень не плохое представление о БД, дочитывайте и параллельно ищите мануал по Data_Pump и RMAN и по-практикуйтесь в восстановлении и бэкапировании БД. И учитесь пользоваться документацией на сайте- лучше ее врятли найдете.
А дальше, сами...

На ваш вопрос невозможно корректно ответить. Каждая СУБД обладает своими архитектурными особенностями и по сути является платформой, т.е. многие полезные вещи уже реализованы. Т.е. можно сравнивать две конкретные СУБД и рамках решения конкретной задачи. Как СУБД для ИС уровня предприятия, Oracle очень хороший выбор, т.к. обычно в таких системах нагрузка 50 на 50(50 запись\50 чтение). И в силу архитектурных особенностей Oracle(реализация транзакций и блокировок) справляется с такой эксплуатацией на ура. Плюс БД еще надо администрировать, заботиться о сохранности данных после сбоя(бэкапирование), туча функций и объектов для реализации бизнес-логики .... короче много всего что нужно делать, и это уже реализовано в Oracle. И как бонус, Oracle более лоялен к рукожопости разработчиков, которые считают, что все БД одинаково работают и устроены. Если данных много и надо быстро их обрабатывать, можно посмотреть в сторону Exadata. Более подробно об особенностях можно почитать в документации. А во всем остальном нужно смотреть под конкретную задачу. Самый большой минус- это стоимость.
З.Ы.: И от себя лично добавлю, на заре карьеры я работал с MS SQL и возненавидел эту СУБД, как раз из-за реализаций транзакций и блокировок, и помогли мне в этом прежние разработчики. В MS SQL блокировки на уровне строк, но реализованы в общем пуле- общий пулл блокировок- это минус скорость(общий пулл надо блокировать, для записи или чтения этих блокировок) и плюс память. И чтобы не загружать особо сервер, прежние разрабы реализовали логику так, что процесс проходил мелкими транзакциями, конечно с коммитами. И были такие прецеденты, что данные удалились, а в другую таблицу не встали из-за ошибки в приложении. Потом дедлоки, это вообще отдельная тема, и приходилось разруливать изменением структуры данных, чтобы пользователи работали, только со своими данными. Короче вспоминаю, как страшный сон. Зато при разработке другой ИС где было решение взять Oracle как СУБД, через призму прошлого опыта, для меня было большое открытие, что там не будет такого гемороя, как с MS SQL. Конечно, может быть MS SQL сейчас сильно изменился в лучшую сторону, но осадочек у меня остался.

Подсказать могу. Ваша задача прекрасно сводиться к ЛП(линейное программирование) и прекрасно ляжет на графы. В учебниках ВУЗовской программы по "Исследованию операций и принятия решений" есть больше, чем достаточно.

Чтобы у вас заработал данный триггер, как минимум вам нужно перечислить во вью обязательные поля. Т.е. из stations нужно добавить 2 st_id(первичные ключи). А все остальное можете взять из документации https://docs.oracle.com/cd/B19306_01/server.102/b1... в примерах.

Добрый день. СУБД под ваши нагрузки и правда можете выбирать любую. Лишь бы секционирование таблиц поддерживало. Postgres- очень хороший выбор. Есть нюанс Postgres, в некоторых случаях, может зависит от прямоты рук(т.е. как вы составите sql запрос). Как и у любой другой БД, есть свои особенности, с которыми вы можете встретиться, а можете не встретиться.
Ключ category+key вместо ID - не очень хорошая идея. Хотя бы поскольку только category имеет 100 символов, еще и key в придачу явно не пустой. Т.к. это первичный ключ по ним будет построен индекс. Ну и представьте, как будут выглядеть листовые блоки в индексах- при поиске в индексе нужного ключа придется по-битово сравнить 100 символов. Не критично, но идея не очень.
Если category повторяется- нормализуйте таблицу(Т.е. значения category вынесите в отдельную таблицу(сущность)) и в таблице MainTable храните внешний ключ(id ключа).
Смысла в поле key не вижу.

Добрый день, Дмитрий Митяев.
Если я правильно понял проблему, то можно воспользоваться cte и join.

with v_idusr_tbl as 
(
select distinct first_value(coj.id_new_owner)over(partition by coj.ceid order by coj.begin_date desc) id_new_owner
 from tver.coj
where coj.ceid=p_ceid
  and trunc(p_date) between trunc(coj.begin_date) and trunc(coj.end_date)
)
, tbl_second_group as (
select distinct first_value(g.name)over(partition by cuj.idusr order by cuj.begin_date desc) name
, cuj.idusr
             from tver.ce_usrgroup_jnl cuj,
                  kollecto.groups g,
                  v_idusr_tbl q
            where cuj.idgrp=g.idgrp
              and g.unique_flag=1
              and (g.name like 'Legal%' or g.name like 'Field%')
              and cuj.idusr=q.id_new_owner
              and trunc(p_date) between trunc(cuj.begin_date) and trunc(cuj.end_date)
)
, tbl_first_group as (
select distinct first_value(g.name)over(partition by cuj.idusr order by cuj.begin_date desc) name
         from tver.ce_usrgroup_jnl cuj,
              kollecto.groups g,
              v_idusr_tbl q
        where cuj.idgrp=g.idgrp
          and g.unique_flag=1
          and (g.name like 'Legal%' or g.name like 'Field%')
          and cuj.idusr=q.id_new_owner
          and trunc(p_date)<=trunc(cuj.begin_date)
          and 0 = (select count(1) from tbl_second_group) /*Если в tbl_second_group ничего нет, то выбираем. 
          Скорее всего, это условие будет выполнено в конце при выполнении запроса, я не придумал способ засунуть в секцию from или exists, чтобы он вообще не выполнялся в случае непустого tbl_second_group*/
)

, tbl_legal_group as (
select name from tbl_second_group 
union all
select name from tbl_first_group 
)
select name into v_legalgroup from tbl_legal_group /*Вставляем в переменнную*/

Все очень опционально.
Если у вы данные в приложение передаете в json, то и храните в json(например, в постгресе хорошая поддержка таких типов полей)
, ключи, как первичные, так и внешние, вынесите в атрибуты таблицы. Этот подход даст большую гибкость в изменении свойств товаров. Я бы начал с него.
Упомянутый unfilled EAV, например, также даст вам возможность гибко менять/добавлять и удалять свойства товаров на странце. Но для получения результирующего набора данных нужно делать много соединений таблиц. А стоимость запроса зависит от многих факторов(наличие\отсутсвии индекса, объем выбираемых данных, соотношение объема к общему объему таблицы, ...) и от вашего скила.
Не бывает хороших или плохих структур\архитектур,а есть только структуры\архитектуры, которые отвечают или не отвечают текущим требованиям. Все очень сильно зависят от реализации и требований. Тут главное не попасть в "ошибку преждевременной оптимизации".
Любой из подходов чреват гемороями и деградации производительности. Тем более приложение будет меняться со временем.
Любая структура БД покажет себя только в реальных условия и на реальных данных и в нагрузке.

Easy:

with function f (p_login varchar2) return varchar2
is
l_retval varchar2(32000);
begin
for x in (select id from t where login = p_login)
loop
 l_retval:= l_retval||'|'||x.id;
end loop;
return l_retval;
end;
select plogin, f(plogin) from (
select distinct login as plogin from t
)
/

Пример выше подойдет только с версии 12 с. Но суть не меняется, оформите в функцию по примеру f.

А чем собственно проблема?
Вы весь json в базу ложите? Или у вас нормализованное представление параметров?
1) Если весь json, то создайте функциональные индексы по столбцу с json, как https://stackoverflow.com/questions/36075918/postg... .
2) Можно еще воспользоваться нормализацией и создать таблицу с аккумулирующая параметры с полями(id_user, param1, param2...) и данные сохранять в таблицу. столбец параметров принимает значение 0, 1. и делать индексы по столбцам. Правда, есть может возникнуть сложности при добавлении нового поля(читай, параметра).
Если просчитать стоимость геморроя решений, то профитнее 1е.

Можно сделать через словарь данных правда уже с помощью Transact-SQL.
https://professorweb.ru/my/sql-server/2012/level3/...

Начни с https://postgrespro.ru/education/courses

Сделайте смещение на константу= 9223372036854775807, т.е. от значение отнимите. Затем чтобы получить значение прибавьте эту же константу.
Если они нужны только для просмотра, храните в тексте.