TheRonCronix

Вот именно teams and users это разные сущности и перемешивать их нельзя. Поэтому и нужно в таблице participants сделать два foreign key. Отдельно на users и отдельно на teams.

select company_name, poll_created_at
from
(
  select company.name as company_name, poll.created_at as poll_created_at,
    row_number() over (partition by company.name order by poll.created_at desc) as rn
  from ...
)
where rn = 1;

Сам pl/sql это лишь часть того что нужно знать. Oracle обширный. Oracle в своей реализации старается дотошно следовать всем стандратам, будь то работа с sql или xml, поэтому можно сугубо оринтрироваться под сам оракл. PL/SQL это ada-подобный язык, довольно простой, на самом деле. Изучить его и использовать не очень сложно.
С точки зрения разработчика я бы выделил три направления в изучении:
- изучение самой СУБД. Можно начать с Oracle database concepts.
- изучение SQL. Тут все просто, в целом Oracle sql - это тот sql, что и везде. Есть, конечно, вариант собственного синтаксиса, но можно и в ANSI писать. что-то простого посоветовать не могу, для детального изучения можно прочитать OCA Oracle Database SQL Exam Guide.
- изучение pl/sql. Есть много ресурсов, книг, официальная документация.
Остальное - пакеты, опции - уже можно черпать из референсов и мануалов Oracle. Например в довесок можно изучить APEX для создания прикладных приложений.
Стоит готовиться к большому кол-ву новой информации.

Не уверен, но скорее всего нет. Можно решить через динамический sql.

Функцией substr

Как вариант:

select distinct DocumentNodeValue, DocumentTemplateName, PatientName, d1.DocumentID, d2.DocumentID
from
(
select DocumentNodeValue, DocumentTemplateName, PatientName, d1.DocumentID, d2.DocumentID, count(*) over(partition by DocumentNodeValue) as repeatitions
from
Patient
join Course on PatientRef = PatientID
join Document d1 on CourseRef = CourseID
join Document d2 on d1.DocumentID = d2.DocumentID
join DocumentTemplate on d1.DocumentTemplateRef = DocumentTemplateID
join DocumentNode on DocumentRef = d1.DocumentID
) as tt
where tt.repeatitions > 1;

Логика такая: разбить весь массив строк на группы по значениям из DocumentNodeValue. В каждой из групп посчитать количество строк. Выдать все строки из массива с подсчитанным количеством. Взять только строки попавшие в группы, в которых насчитано более 1 строки. + distinct на ваше усмотрение.

Посчитать можно, для этого придется пройтись по всем строкам таблицы и для каждой из точек высчитать расстояние до вашей точки, а потом отсортировать. Но, если нужно выбрать лишь несколько ближайших точек или просто точки не слишком удаленные от заданной, то можно воспользоваться техникой bounding-box: представить, что вокруг точки куб или квадрат заданного размера и провести вычисление сначала в границах куба. Это позволит хоть как-то задействовать индексы.

Даю идею (синтаксис не проверял):

select mod(rn, N) part_number,
t1.*
from
(
select t.*,
row_number() over() rn
from table as t
) as t1

N - кол-во частей, table - ваша таблица.

СУБД рассчитаны на то, чтобы не зависеть от клиентского приложения. В большинстве случаев, если не пул соединений используется, то под каждого клиента создается свой процесс. Можно легко завесить свой клиентский процесс, но не чужие. Однако, можно попробовать замедлить работу СУБД, влияя на разделяемые ресуры, например, вытеснить из кэша разобранные запросы путем генерации множетсва отличающихся запросов. Не факт, что сработает. Или блокировать доступ к таблице или процедуре путем ее перекомпиляции. Чтобы СУБД реально зависла, для этого нужен баг в СУБД. Но такие ситуации очень индивидуальны. На моей практике был только один такой случай, когда запрос ронял всю СУБД.
Темой атак на СУБД я не занимался, но вопрос задали интересный.

Не составной ключ как столбец можно назвать просто id, можно имя_таблицы_id. На мой взгляд оба варианта допустимы.
Важно скорее придерживаться одного стандарта, т.к. это благоприятно скажется при разного рода автоматизации.
имя_таблицы_id может быть более выгоден в случае, если у вас есть две разные таблицы, но по смыслу имеющие один и тот же первичный ключ. Т.е. бизнес-смысл у него один. Также в выборках, где в качестве алиасов используются короткие одно-двух буквенные последовательности и выбирабтся несколько id, то может быть трудно понять какой id из какой таблицы. В целом я склоняюсь к варианту с осмысленными названиями, т.к. осмысленное название лучше, чем не осмысленное, т.е. я бы выбрал имя_таблицы_id.
Сам же первичный ключ как констрейнт имеет смысл называть: pk_имя_таблицы

Самый простой способ - использовать комбинацию функций instr/substr

Вероятно в слове "сategory" имеются нелатинские символы.

Вариантов оптимизации может быть несколько, в зависимости от версии СУБД, распределения данных. Например, можно сначала рассчитать свертку

SELECT count(*), item_id, param_id, value
FROM values_product
GROUP BY item_id, param_id, value;

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