Евгений

Использования нативных запросов следует избегать. Они нужны только в тех редких случаях, когда возможностей ORM не хватает, но и отказываться от ORM не хочется.

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

Criteria API наоборот многословен и лучше подходит для сложной логики работы с базой, зато позволяет отловить ошибки ещё на этапе компиляции и динамически построить запрос.

.mergeMap(() => this.httpClient.get('https://api.github.com/users'), (event, users) => ({ event, users }))

Поскольку вопрос о трансформации имеющихся данных - то индивидуально для каждой задачи.

Начать необходимо вот отсюда: https://habrahabr.ru/post/146901/
И, собственно, придти к выводу, что лучше оставить как есть в одном поле. Если в каких-то местах нужны другие формы обращений - прописать их явно, а не конструируя по имеющимся заблуждениям о фио.

А так:
0) делается дополнительный бекап
1) выкатывается alter table добавляющий новый поля
2) выкатывается приложение, умеющее писать синхронно старую и новую структуру, но читающее только старую
3) отдельным процессом в цикле небольшими частями преобразуются данные - это если подлежит автоматической обработке
4) выкатывается приложение использующее только новую структуру
5) архивируется и удаляется исходная структура

Для всего-то тысячи записей может проще будет залочить табличку на несколько секунд.

Если тривиальной автоматике обработка не подлежит, то часто вместо 3 пункта делают выгрузку primary key, source_data, как-нибудь изменяют и готовят csv primary key, source_data, new_data, копируют в temporary table, затем делают слияние мультитабличным update этих двух таблиц с recheck'ом по source_data. Затем выгружают данные для которых не было обновления, разбираются, ещё раз обновляют и т.д. до заполнения всего.

Мне кажется, самый простой пример замыкания - это счетчик.

var counter = (function () {
	var current = 0;
	return function () {
		current++;
		return current;
	}
})();

console.log(counter()); // 1
console.log(counter()); // 2

В данном случае мы не имеем доступ к переменной current и функция гарантированно возвращает каждый раз уникальное значение.
Если бы это была простая функция, то переменная, содержащая состояние (current), должна была бы находиться вне функции.

var current = 0;
var counter = function () {
	current++;
	return current;
}

console.log(counter()); // 1
current = 5;
console.log(counter()); // 6

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

Пользу от тестов замечаешь только тогда, когда начинаешь писать что-то сложнее hello world'ов. Особенно хорошо их видно, когда приложение разрабатывается уже несколько лет и более, чем десятком разработчиков. Изменяешь какую-то часть кода, запускаешь тестирование и видишь, что теперь другой участок кода тестирование не проходит, так как в прошлом году у разработчика, которого ты даже не встречал, протекла абстракция.

взять весь контент.... получить с него теги.... отсортировать теги... подчитать их количество..

SQL - декларативный язык, пришла пора узнать об этом побольше )