ponaehal

сами понятия "начало БД" и "конец БД" абсолютно неверны. Данные в большинстве реляционных БД хранятся в неотсортированном виде. СУБД сама решает "в какое место таблицы" вставить запись.
Как уже правильно сказали коллеги выше, правильно добавить фразу ORDER BY <поле сортировки> <порядок сортировки - ASC|DESC> в тот запрос, который выводит Ваши данные в пользовательском интерфейсе.

Ребенок учится быстро ходить абсолютно в любом направлении.... и даже бегать тоже учится достаточно быстро.... а вот что бы на дистанции 100 метров показать хотя бы уровень КМС, понадобятся годы.
Я это к чему?!... не надо выбирать быстрый путь (т.к. пройдя по быстрому пути вы будете всего лишь заурядным специалистишком), выберите тот путь, по которому вам будет приятно идти долго и вы сможете достичь максимально возможного для вас уровня.
По этому вопрос я бы адресовал прежде всего Вам. А чем именно Вам интересно было бы заниматься?

1. Спросить у работника: а ты хочешь быть начальником? Человек должен быть морально готов отпустить компетенции по программированию и приобрести новые компетенции (планы, люди, сроки и пр. менеджерские вопросы). Ему это надо объяснить. Сформировать ожидания от него.
2. Человек по натуре должен быть экстравертом. Предпочитать общение с людьми копанию в коде. Думаю это видно невооруженным взглядом.
3. Как это не банально звучит - лидерство. Умение и желание делиться компетенциями, горящие глаза, высокая самомотивация и пр. Если человек у вас работает, то это видно невооруженным глазом. На собеседовании это не очевидно.
4. А еще можно устроить "тестдрайв", например назначить его на роль РП, наделить всей полнотой власти функционального руководителя и посмотреть как справится (тут есть несколько НО).

ИМХО (не проверял):
CASE... END * 10 as date_value, date_value + tags_count as test
Вы обзываете столбец и пытаетесь этот алиас тут же использовать. Видимо именно это не нравится интерпретатору.

Сработает так:

1. SELECT date_value, date _value*tags_count FROM (SELECT CASE... END as date_value , tags_count FROM "articles" ....)

или так:
2. SELECT
CASE ... END as date value,
CASE .... END *tags_count as date_value2
FROM "articles" ....

Про переменные надо говорить в контексте среды разработки в которой планируете выполнять запрос. Если говорить об SQLPlus, то как то так (слямжено с SQL.ru):

SET DEFINE "&"
VAR db_name VARCHAR2(30)
COLUMN db_name NEW_VALUE db_name
EXEC :db_name := 'Blah';
SELECT :db_name AS db_name FROM dual;
DEFINE db_name

Судя по описанию проблематики, выбор среды разработки - это не самая большая Ваша проблема :). Выбирайте любую, например, по наличию дистрибутива.

SELECT TOP 1 id FROM people WHERE name = 'Ann'

Хм... Для оракла я бы выкрутился так:

SELECT  
t2.datetime
, param2
, (SELECT param1 
  FROM
     (SELECT 
         t1.param1 
      ,  row_number() OVER(ORDER BY t1.datetime DESC)  rankparam1
      FROM table1 t1  
      WHERE t2.datetime>=t1.datetime)  
   WHERE rankparam1 = 1)
  as param1
FROM table2  t2

Полагаю в других база примерно так же.
Но сильно не уверен что это будет достаточно быстро (даже если правильно расставить индексы).

ИМХО, если такой вопрос возник, то ВОЗМОЖНО что -то делаете не так. Вещать бизнес-смысл на IDб основная цель которых обеспечить уникальность - это в общем случае не очень правильно.
Тем не менее...
Возможно есть более красивое решение, но сходу не приходит в голову (для каждой БД оно будет свое).
Общий подход:
1. Создаем таблицу t2 с большим количеством строк и с одним полем num. В цикле заполняем ее значениями от 1 до n.
2. В запросе минусуем исходную таблицу из t2
SELECT t.num FROM t2
EXCEPT
SELECT t.id FROM base_table t
все.

ЗЫ Если таблицу делать лень, а число записей небольшое, то можно воспользоваться
SELECT unnest(array[1, 2, 3, 4)

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

А что бы творческие мытарства дизайнера не приходилось по 20 раз переделывать, посадите рядом с ним аналитика.

Полу-милорд, полу-купец,
Полу-мудрец, полу-невежда,
Полу-подлец, но есть надежда,
Что будет полным наконец.

Пушкин А.С. когда это говорил имел ввиду, что если выбираете стязю программирования, то чем быть полуспециалистом по тридцати технологиям, лучше в совершенстве освоить одну.
Так и сказал.

так работает?

UPDATE
    sales as s
SET s.plan_payment_date = (SELECT 
                                                       MAX(pay.payment_date) 
                                                   FROM 
                                                       payments pay
                                                   ,  payments_parts pp
                                                   WHERE pay.ID = pp.FK_payment
                                                          and s.ID = pp.FK_sale 
                                             )

Хотя сам бы за такое пальцы отрубил бы исполнителю )))

INSERT INTO tab1 (f1,f2,f3) SELECT v1,v2,v3 FROM tab2

Count - групповая функция. Что бы запрос с Count работал, необходимо выполнение одного из следующих условий:
1. Count - только одно поле в списке выбора. T.е. SELECT count(*) from ...
2. Проведена группировка по всем атрибутам в списке выбора. SELECT fio, bdate, count(*) from tab group by fio,bdate.
Второй случай похоже покрывает ваши потребности.

На Вашем есте я бы еще посмотрел на аналитические функции COUNT(..) OVER (PARTITION BY ... ) имхо работать будет быстрее чем COUNT(..) GROUP BY..., но не понимая задачи не знаю насколько можно использовать в Вашем случае

1. Появление дублей в таблице лучше исключить в принципе, а не чистить постфактум. В целом это создаст более равномерное распределение данных по блокам БД и положительно скажется на общей производительности. Если дубли "плодит" какое то приложение, на которое Вы не можете повлиять, то рассмотрите возможность применения триггеров на таблице AccountItems .
2. В результате выполнения п.1. Ваш запрос станет проще. А если еще посмотрите в план запроса, добавите необходимые индексы, разобьете AccountItems на партиции, то есть шанс сделать совсем хорошо.

В принципе можно решить и "в лоб" но лень...

В порядке бреда:
Заполнить таблицу временными минимальными доступными временными интервалами в промежутке с 9 до 18 (создать расписание).
В вашем случае это будет 18 тридцатиминутных интервалов (всего 18 строк).
Далее, например, в случае резервирования на час, резервировал бы сразу 2 интервала.

А потом все сводится к банальному UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 30 равен 0>
UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 45 равен 0>
UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 60 равен 0>
UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 90 равен 0>

Если Oracle, то гуглите слова SELECT CONNECT BY PRIOR

По ощущениям, спасет коррелированный подзапрос. Как то так:
SELECT * FROM securities t
WHERE t.change_date IN (SELECT Max(t1.change_date) FROM securities t1 WHERE t.section=t1.section)
Если будет долго работать, то подозреваю, что можно придумать что-нибудь более производительное с использованием аналитических функций...