Станислав Макаров

1. Создание tcp-соединения медленное;
   
2. Создание tls-соединения ещё медленнее;
   
3. Установка соединения протокола уровня приложения ещё медленнее;
   
4. Аутентификация подключения на порядок медленнее;
   
5. Создание сессии для соединения системой управления базами данных такая же медленная;
   
6. Завершение сессии и освобождение ресурсов медленное;
   
7. Закрытие соединение относительно быстрое, но тоже не мгновенное.
   

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

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

Будут ли запросы в самой базе сериализоваться в очередь либо выполняться параллельно - вопрос к этим самым запросам. Читающие довольно сложно чем-то заблокировать, пишущие чаще могут конфликтовать за блокировки.

Пишется достаточно просто. Все что вам нужно:
- знание функций, которые позволяют работать с реестром. Они есть по моему в winAPI, ну или гуглятся очень быстро
- какой то фреймворк для простого формошлепства. Если навыков все равно нет - Qt рекомендую.

Главное разделите модель, данные и вьюху - не пытайтесь сразу нарисовать дерево реестра напрямую.

1. Выделить одну главную функцию сервиса
2. Сделать её, сверстать и выкатить, это будет MVP
3. Не заморачиваться с вёрсткой
4. Не заморачиваться с методами авторизации
5. Не думать про нагрузку, не заниматься оптимизацией кода и БД
6. Если поймали себя на мысли что вы думаете какой паттерн тут применить вы в Ж, просто пишите код, который работает!!
7. Не совмещать написание сервиса, который вы РЕАЛЬНО хотите запустить с изучением чего-то нового (языка, БД). Утоните в учёбе и никогда не запустите.

Это всё на своём опыте написания проекта говорю вам а не голословно ))

Потому что контекст не сохраняется, в setTimeout вызывается функция с глобальным контекстом. Варианты решения:
Забиндить контекст:
setTimeout(user.sayHi.bind(user), 1000);
Или же вызвать в анонимной функции
setTimeout(() => user.sayHi(), 1000);

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

Во-первых, гипотеза лингвистической относительности утверждает, что чем больше языков знаешь, тем гибче и богаче твой логический аппарат. По своему опыту могу сказать, что это правда. Например изучение Lisp'ов существенно расширило мои возможности в других языках. Но мой опыт и мнение не так авторитетны, как авторов всемирно известного бестселлера "Программист-прагматик" - Эндрю Ханта и Дэвида Томаса, которые пишут: «Изучайте по крайней мере один новый язык ежегодно. Разные языки решают одни и те же проблемы разными способами. Изучив несколько разных подходов, вы сможете расширить свой кругозор и не погрязнуть в рутине.»

Во-вторых, рано или поздно профессиональный рост java-программиста, например, неизбежно приводит его к необходимости глубоко понимать работу компилятора и виртуальной машины, а это невозможно без знания C++, на котором они написаны.

В-третьих, java-программист свободно лазающий за ответами в исходники JVM, способный дебажить сборщик мусора, писать JNI-библиотеки и использовать Compiler API для метапрограммирования имеет больше предложений работы и более выгодные условия.

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

Проект не надо заканчивать. Его надо запускать как можно быстрее и потом итеративно развивать.
Не удивительно, что ни в одной кинги по программированию про это не пишут. Ведь к собственно навыку написания кода это отношения не имеет никакого.

Если хочется "четко и красава чтоб не хуже чем у пацанов", гляньте на либу Polly:

public async Task<List<AccountListView>> GetAsync()
{
	var policy = Policy
		.Handle<UnauthorizedException>()
		.RetryAsync(
			retryCount: 1,
			onRetryAsync: (e, i) => Context.Renew());

	return await policy.ExecuteAsync(TryGetAccountListAsync);
}

Созданную policy можно переиспользовать. Т.е. вам не придется больше плодить копипасту, достаточно объявить одну политику на приложение, и дальше просто вызывайте то что требует обновления токена через эту политику.

$stmt = $this->dbh->prepare("SELECT * FROM z_setting WHERE `key`=:key");